COBOL metamodel

ABSTRACT

A method of and a system for processing an enterpise an application request on an end user application and an application server. This is accomplished by initiating the application request on the end user application in a first language (such as a markup language) with a first application program (such as a Web browser), and transmitting the application request to the server and converting the application from the first language of the first end user application to a language running on the application server, processing the application request on the application server, and transmitting the response from the application server back to the end user application, and converting the response from the language running on the application server to the language of the end user application. The end user application and the application server have at least one connector between them, and the steps of (i) converting the application request from the language of the end user application (as a source language) to the language running on the application server (as a target language), and (ii) converting the response to the application request from the language running on the application server (as a source language) to the language of the end user application (as a target language), each include the steps of invoking connector metamodels of the respective source and target languages, populating the connector metamodels with metamodel data of each of the respective source and target languages, and converting the source language to the target language.

CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit under Title 35, United StatesCode, Sections 111(b) and 119(e), relating to Provisional PatentApplications, of the filing date of U.S. Provisional Patent ApplicationSer. No. 60/223,671 filed Aug. 8, 2000 of Steven A. Brodsky and Shyh-MeiHo for EAI Common Application Metamodel.

[0002] This application is also related to the following United StatesPatent Applications, filed on even date herewith:

[0003] COMMON APPLICATION METAMODEL by Shyh-Mei Ho, Stephen Brodsky, andJames Rhyne,

[0004] PL/I METAMODEL by Shyh-Mei Ho, Peter Elderon, Eugene Dong andTony Tsai.

[0005] HIGH LEVEL ASSEMBLER METAMODEL by Shyh-Mei Ho, John Ehrman,Benjamin Sheats, and Jenny Hung.

[0006] TYPE DESCRIPTOR METAMODEL by Shyh-Mei Ho, James Rhyne, PeterElderon, Nick Tindall, and Tony Tsai.

[0007] IMS TRANSACTION MESSAGES METAMODEL by Shyh-Mei Ho and ShahafAbileah.

[0008] IMS-MFS (MESSAGE FORMAT SERVICE) METAMODEL by Shyh-Mei Ho,Benjamin Sheats, Elvis Halcrombe, and Chenhuei J. Chiang.

[0009] CICS-BMS (BASIC MESSAGE SERVICE) METAMODEL by Shyh-Mei Ho, AndyKrasun, and Benjamin Sheats.

FIELD OF THE INVENTION

[0010] The invention relates to exchanging instructions and/or databetween applications to signal readiness to transfer, exchange, orprocess data, or to establish at least one or more parameters fortransferring data between the applications, and controlling theparameters in order to facilitate data transfer and communication. Theinvention further relates to integrating dissimilar applications oneexecuting within one platform and another executing in another platform,e.g., multiple computers, multiple operating systems, multipleapplication components, multiple development environments, multipledeployment environments, or multiple testing and processing,establishing a dialog (e.g., a negotiation) with one another in order toestablish connectivity for transferring data and/or instructions betweenthe applications so as to facilitate performing tasks on the data orportions thereof to accomplish an overall goal. The parameters mayinclude one or more of format, data types, data structures, or commands.

BACKGROUND

[0011] The growth of e-business has created a significant need tointegrate legacy applications and bring them to the Internet This isbecause the current trend for new applications is to embrace Webstandards that simplify end user application construction andscalability. Moreover, as new applications are created, it is crucial toseamlessly integrate them with existing systems while facilitating theintroduction of new business processes and paradigms.

[0012] Integrating new applications with existing applications isespecially critical since industry analysts estimate that more thanseventy percent of corporate data, including data highly relevant toe-commerce, lives on mainframe computers. Moreover, while manye-commerce transactions are initiated on Windows, Mac, and Linux enduser platforms, using a variety of Web browsers, and go through WindowsNT and Unix servers, they are ultimately completed on mainframecomputers, running mainframe applications, and impacting data stored inmainframe databases.

[0013] There are e-business pressures to integrate server levelapplications and bring them to the Internet. However, there is nocomplete and easy mechanism to integrate or e-business enable theapplications. Integration, whether through messaging, procedure calls,or database queries, is key to solving many of today's businessproblems.

[0014] Integrating legacy applications with new software is a difficultand expensive task due, in large part, to the need to customize eachconnection that ties together two disparate applications. There is nosingle mechanism to describe how one application may allow itself to beinvoked by another.

[0015] One consequence is an e-commerce environment of multipleapplications, developed by multiple development teams, running ondifferent platforms, with different data types, data structures,commands, and command syntax's. This environment is stitched togetherwith application program interfaces and connectors. Connectors are anessential part of the total application framework for e-commerce.Connectors match interface requirements of disparate applications andmap between disparate interfaces.

[0016] This growing interconnection of old and new software systems andapplications, has led to various middle ware applications and connectorapplications, interface specifications, interface definitions, and code,especially for the interconnection and interaction of markup languages(such as HTML, XML, Dynamic HTML, WML, and the like), through objectoriented languages such as SmallTalk and C++, with languages of legacyapplication server applications (such as COBOL). These interfacespecifications, definitions, and code should apply across languages,tools, applications, operating systems, and networks so that an end userexperiences the look, feel, and responses of a single, seamlessapplication at her terminal. Instead, the proliferation of standards,protocols, specifications, definitions, and code, e.g., Common ObjectRequest Broker (CORBA), Common Object Model (COM), Object Linking andEmbedding (OLE), SOM, ORB Plus, Object Broker, Orbix, has insteadcreated an e-commerce “Tower of Babel.”

[0017] Examples of application integration are ubiquitous: frominstalling an ERP system, to updating an Operational Data Store (ODS)with IMS transactions or invoking CRM systems from MQSeries; each ofthese requires the same basic steps. First, a user must find the entityshe wants to communicate with, then she must figure out how to invokethe entity, and finally she must provide translation from one nativerepresentation to another. Today, these steps usually require manualinvestigation and hand coding—and leave the developers with a rat's-nestof hard-to-maintain connections between applications.

[0018] Attempts to remedy this situation involve application programinterfaces and connectors, which are frequently built on InterfaceDefinition Languages. Interface Definition Languages are declarative,defining application program interfaces, and, in some cases, issues suchas error handling. Most Interface Definition Languages are a subset ofC++, and specify a component's attributes, the parent classes that itinherits from, the exceptions that it raises, the typed events that itemits, the methods its interface supports, input and output parameters,and data types. The goal of Interface Definition Languages withinconnectors is to enable collaboration between dissimilar applicationswithout hard coded application program interfaces.

[0019] Ideally, the interface definition language, and the connector ofwhich it is a part, should facilitate full run-time software applicationcollaboration through such features as

[0020] Method invocation with strong type checking,

[0021] Run-time method invocation with greater flexibility and run timebinding,

[0022] High level language binding, with the interface separated fromthe implementation.

[0023] An interface repository containing real time information ofserver functions and parameters.

[0024] Additionally, the connector and its interface definitionlanguage, should be fast, efficient, scalable, portable, supportmetaclasses, support syntactic level extensions, and support semanticlevel extensions.

SUMMARY OF THE INVENTION

[0025] The problems associated with integrating new applications, forexample, e-commerce applications, with legacy applications are obviatedby the Common Application Metamodel tool, method, and system describedherein. The Common Application Metamodel method, tool, and system of theinvention facilitate tooling solutions, data translation, andcommunication and collaboration between dissimilar and disparateapplications, as well as full run-time software applicationcollaboration through an interface with the application server interfacedomain. This is accomplished through metadata interchange information,method invocation with strong type checking, run-time method invocation,run time binding, and high level language binding, with the interfaceseparated from the implementation, and an interface repositorycontaining real time information of client and server interfaceparameters.

[0026] Additionally, the tool, method, and system of the inventionprovide fast, efficient, and scalable interconnectivity independently ofany tool or middleware, are reusable and portable, and supportmetaclasses, syntactic level extensions, and semantic level extensions,and are independent of any particular tool or middleware.

[0027] The Common Application Metamodel tool, method, and system isespecially useful for providing a data transformer that is bidirectionalbetween a client application and a server application, transmittingcommands and data both ways between, for example, a Java, HTML, XML, C,or C++ application and a COBOL application.

[0028] One embodiment of the invention is a method of processing atransaction on or between an end user application and one or moreapplication servers. The method comprises the steps of initiating thetransaction on the end user application in a first language with a firstapplication program, transmitting the transaction to the server, andconverting the transaction from the first language of the first end userapplication to a language running on the application server. Typically,as described above, the client will be a thin client or a Web browser,the application running on the client will be a Web browser applicationor a thin client connectivity application, and the language of theclient application will be Java, C, C++, or a markup language, as HTMLor a derivative of HTML, such as XML or Dynamic HTML or WML, or thelike, and the language running on the server is COBOL. The inventionfacilitates transformers which convert the transaction from the firstlanguage of the end user application to a language running on theapplication server. After conversion, the converted transaction isprocessed on the application server.

[0029] The application processes the request and then sends the responsefrom the application server back to the end user application. Typically,as described above, the application server will be running a COBOL basedapplication, and the client will be a thin client written in Java or Cor C++, or a Web browser, running a Web browser application or a thinclient connectivity application, in a markup language, as HTML or aderivative of HTML, such as XML or Dynamic HTML, or the like. Theinvention provides data transformers which convert the response from thelanguage or languages running on the application server or servers tothe first language of the first end user application.

[0030] The end user application and the application server have at leastone data transformer between them. In this way, the steps of (i)converting the request from the first language of the first end userapplication as a source language to the COBOL language running on anapplication server as a target language, and (ii) converting theresponse from the COBOL language running on the application server, as asubsequent source language, back to the first language of the first enduser application, as a subsequent target language, each comprise thesteps of invoking type descriptor and language metamodels of respectivesource and target languages, populating the metamodels with each of therespective source and target languages' data items and types, andconverting the source language to the target language.

[0031] The end user application is, frequently, a web browser or a thinclient. When the end user application is a Web browser, the end user isconnected to the application server through a web server. According to afurther embodiment of the invention, the web server may comprise theconnector, or data transformer. The data transformer integrated with theWeb server may directly convert the request, transaction, or messagefrom a browser oriented form to an application server language or to anintermediate, business or commerce oriented markup language, such asXML.

[0032] The CAM metamodel used to construct the converter comprises aninvocation metamodel, an application domain interface metamodel, alanguage metamodel, and a type descriptor metamodel. Exemplaryinvocation metamodel includes information chosen from the groupconsisting of message control information, security data, transactionalsemantics, trace and debug information, pre-condition and post-conditionresources, and user data, etc. Exemplary application domain interfacemetamodel comprises information chosen from input parameter signatures,output parameter signatures, and return types. Application domaininterface metamodel uses one or more language metamodels, such as COBOLmetamodels.

[0033] The type descriptor metamodel defines physical realizations,storage mapping, data types, data structures, and realizationconstraints.

[0034] The method of the invention is applicable to situations where oneof the source or target languages is object oriented, and the other ofthe target or source languages is not object oriented. In thissituation, the language metamodel and the type descriptor metamodeltogether map encapsulated objects of the object oriented language intocode and data of the language that is not object oriented. Additionally,the language metamodel and the type descriptor metamodel maps objectinheritances of the object oriented language into references andpointers in the language that is not object oriented. The method of theinvention is also applicable where different procedural languages arerunning on different platforms or applications and commands and data ofthe source procedural language are mapped into the target procedurallanguage.

[0035] According to the method of the invention, there may be aplurality of applications for vertical (sequential, conditional, ordependent) processing, for horizontal (parallel in time) processing, orboth horizontal and vertical processing. This is to support richtransactions to and through multiple hierarchical levels and multipleparallel sequences of processing. This may be the case in business tobusiness transactions drawing upon financial, manufacturing, scheduling,supply, and shipping databases and servers, and utilizing variouscommercial security instruments.

[0036] A further aspect of the invention is a client-server processingsystem having a client, a server, and at least one transformer betweenthe client and one or more servers.

[0037] A still further aspect of the invention is a processing systemconfigured and controlled to interact with a client application. In thisaspect of the invention, the system comprises, a server, and at leastone transformer between the server and the client application, where theclient has an end user application, and is controlled and configured toinitiate a request with the server in a first language with a firstapplication program and to transmit the request through a transformer tothe server or servers. The server processes the request in a secondsoftware application, using a second language, and returns a response tothe client through a transformer.

[0038] A further aspect of the invention is a groupware system having aplurality of e-mail enabled end user applications, such as e-mail, wordprocessing, spreadsheet, simple database management (such as LotusApproach or Microsoft Access), graphics and graphics editing, audio andaudio editing, and computer-telephony integration (“CTI”), along withclient level content database client services and content replicationclient services. Groupware integrates these e-mail enabled applicationsthrough one or more transformers and application program interfaces withtransport services, directory services, and storage services, includingcontent servers and replication servers. The groupware system isconfigured and controlled to communicate among disparate end userapplications, among disparate servers, and between disparate servers andend user applications. The groupware system comprises at least onetransformer between a server and an end user application. The end userapplication is controlled and configured to participate with a server ina first language of a first application program and the server isconfigured and controlled to participate with the client in a secondlanguage of a second program.

[0039] The transformer is configured and controlled to receive a requestfrom the end user application, and convert the request from the firstlanguage of the first end user application to a language running on theserver. The server is configured and controlled to receive the convertedrequest from the transformer and process the request in a secondlanguage with a second application program residing on the server, andto thereafter transmit a response through a transformer back to the enduser application.

[0040] A still further embodiment of the invention is the provision ofrich transaction processing. Rich transactions are nested transactionsthat span to, through, and/or across multiple servers. The spanningacross nested servers may be horizontal, that is parallel dependenttransactions, or vertical, that is, serial dependent transactions. Richtransactions may be long lived, on-going transactions, or complexbusiness-to-business transactions, especially those with multipledependencies or contingencies, volume and prompt payment discounts, latedelivery and late payment penalties, and with financial processing, suchas electronic letters of credit, electronic bills of lading, electronicpayment guarantees, electronic payment, escrow, security interests inthe goods, and the like. In a rich transaction environment, sometransaction servers may be positioned as clients with respect to othertransactions for certain sub transactions making up the richtransaction.

[0041] A still further embodiment of the invention is a tool, that is, asoftware developer's kit, characterized in that the program product is astorage medium (as a tape, floppy disks, a CD-ROM, or a hard drive orhard drives on one of more computers) having invocation metamodels,application domain interface metamodels, and language metamodels, andcomputer instructions for building a metamodel repository of source andtarget language metamodels. The program product also contains computerinstructions for building connector stubs from the metamodels. Theprogram product further carries computer instructions to build atransformer.

[0042] While the invention has been described in summary form as havinga single level of connectors, it is, of course, to be understood thatsuch connectors may be present at various levels in the processinghierarchy, for example between Web Clients and Web servers, between webservers and application servers, between application servers anddatabase servers, and between application servers or database servers orboth and various specialized repositories.

[0043] It is also to be understood, that while the invention has beensummarized in terms of individual clients and individual servers, theremay be multiple clients, multiple servers, and applications thatfunction as both clients and servers, as exemplified by groupwareapplications, and there might be multiple parallel lines and/or multiplehierarchical levels of application servers, data servers, and databases,as in systems for rich transactions.

THE FIGURES

[0044] Various elements of the invention are illustrated in the FIGURESappended hereto.

[0045]FIG. 1 illustrates a system with multiple application components,including a Netscape Internet Explorer browser, Net.Commerce on a SunSolaris server, Oracle and DB2 on a database server, SAP running on AIX,a CICS 390 server, an IMS 390 server, DB2 and DL/I on a S/390 platform,a Windows 200 client, and Baan running on an HP Unix server.

[0046]FIG. 2 illustrates the roles of message sets, SQL storedprocedures, legacy applications, and programming languages as inputs tothe metadata repository of the Common Application Metamodel tofacilitate enterprise application integration at run time.

[0047]FIG. 3 illustrates that the Common Application Metamodel of theinvention consists of three kinds of metamodels, i.e., an invocationmetamodel, an application-domain interface metamodel, and a languagemetamodel. For any given application-domain metamodel it may use one ormany language metamodels, and there could be zero or many invocationmetamodels.

[0048]FIG. 4 illustrates an IMS OTMA metamodel, with an OTMA InvocationMetamodel, an IMS Transaction Message Metamodel application interface,which could use a COBOL Metamodel, a C Metamodel, or other languagemetamodels.

[0049]FIG. 5 illustrates how a tool can be used to generate an XMLdocument describing application program interface. First, an objectmodel, i.e., a CAM metamodel, is created to capture interfacedefinitions about an application server. Then a tool reads and parsesthe source definitions of an application program and generates an XMLdocument by retrieving the object model's information from a repository.

[0050]FIG. 6 illustrates a development phase scenario where a CommonApplication Metamodel Rose file, e.g., a COBOL metamodel, a PL/Imetamodel, an MFS metamodel, a BMS model, or the like is read into atoolkit, to generate a DTD and XML schema and Java code for a Rosemodel. A source file of an application, as a COBOL source file, a PL/Isource file, an MFS source file, a BMS source file, or the like, is readinto an importer. The importer parses the source code and generates, asoutput, an XMI instance file, i.e., XML documents, by reading in theJava code of the Rose model of the application source files.

[0051]FIG. 7 illustrates a metamodel for application interfaces, whichenables integration of application components into an event basedmessaging model, including flow models. The flow and messaging middleinvokes applications through the application interface. These interfacesare access points to the applications through which all input and outputis connected to the middleware. The interfaces are described in terms ofthe Application Interface Metamodels. Transformation processingaccording to he metamodel could take place in source/clientapplications, target applications, or a gateway.

[0052]FIG. 8 illustrates the application of the Common ApplicationMetamodel during execution time. As shown, the CAM model facilitatesconnectivity between a back-end IMS application and a Web file (e.g.,SOAP complaint XML documents). This is accomplished by using informationcaptured in the model to perform data transformations from one platformto another in a mixed language environment shown.

[0053]FIG. 9 illustrates TDLang base classes, where the Type Descriptormetamodel is used as a recipe or template for runtime datatransformation, with the language specific metamodel for overall datastructures and field names, and without duplicating the aggregationassociations present in the language model.

[0054]FIG. 10 illustrates an MOF class instance at the M2 level as aType Descriptor Metamodel.

[0055]FIG. 11 illustrates the association between a TDLangElement of theTDLang Metamodel with a Platform Compiler Type of the Type DescriptorMetamodel.

[0056]FIG. 12 illustrates various enumeration types for the TypeDescriptor Metamodel, e.g., sign coding, length encoding, floating type,accessor, packed decimal sign, and bitModelPad.

[0057]FIG. 13 illustrates a COBOL metamodel to define data structuresemantics which represent connector interfaces. This metamodel is also aMOF Class instance at the M2 level.

[0058]FIG. 14 illustrates the associations between the COBOL metamodelwith the TDLang base classes which are the TDLangClassifier, theTDLanguageComposedType, and the TDLangElement.

[0059]FIG. 15 illustrates an enumeration of the COBOL usage values inthe COBOL Metamodel.

[0060]FIG. 16 illustrates a simplified network configuration for a“rich” transaction where, for example, an order is entered at aterminal, and is passed to and through a Web server to a manufacturer'sapplication server. The manufacturer's application server searchesthrough it's own database server, as well as its vendors' dissimilar andincompatible database servers and databases, transparently connected bythe connectors described herein, querying for statuses, prices, anddelivery dates, of components, and placing orders for needed componentsto satisfy the order.

[0061]FIG. 17 illustrates a group ware session spread across multiplegroup ware applications running on multiple, disparate platforms, andconnected using the common application metamodel described herein.

[0062]FIG. 18 illustrates a commercial transaction where real goods areshipped from a seller to a buyer, and various forms of electronicpayment and secured electronic payment are used by the buyer to pay theseller, with banks and financial institutions connected using the commonapplication metamodel described herein.

DETAILED DESCRIPTION OF THE INVENTION

[0063] Definitions.

[0064] As used herein the following terms have the indicated meanings.“Handshaking” is the exchange of information between two applicationsand the resulting agreement about which languages, capabilities, andprotocols to use that precedes each connection.

[0065] An “application program interface” (API) is a passive specificmethod prescribed by a computer operating system or by anotherapplication program by which a programmer writing an application programcan make requests of the operating system or another application.Exemplary is SAX (Simple API for XML), an connector that allows aprogrammer to interpret a Web file that uses the Extensible MarkupLanguage, that is, a Web file that describes a collection of data. SAXis an event-driven interface. The programmer specifies an event that mayhappen and, if it does, SAX gets control and handles the situation. SAXworks directly with an XML parser.

[0066] A “connector” as used herein is a dynamic, run-time, interfacebetween platforms that stores the functions and parameters of the targetplatform or program, and binds with the target platform program in realtime.

[0067] A “stub” is a small program routine that provides staticinterfaces to servers. Precompiled stubs define how clients invokecorresponding services on the server. The stub substitutes for a longerprogram on the server, and acts as a local call or a local proxy for theserver object. The stub accepts the request and then forwards it(through another program) to the remote procedure. When that procedurehas completed its service, it returns the results or other status to thestub which passes it back to the program that made the request. Serverservices are defined in the stub using an Interface Definition Language(“IDL”). The client has an IDL stub for each server interface that itaccesses and includes code to perform marshaling. Server stubs providestatic interfaces to each service exported by the server.

[0068] “CICS” (Customer Information Control System) is the onlinetransaction processing program from IBM that, together with the CommonBusiness Oriented Language programming language, is a set of tools forbuilding customer transaction applications in the world of largeenterprise mainframe computing. Using the programming interface providedby CICS to write to customer and other records (orders, inventoryfigures, customer data, and so forth) in a CICS, a programmer can writeprograms that communicate with online users and read from a database(usually referred to as “data sets”) using CICS facilities rather thanIBM's access methods directly. CICS ensures that transactions arecompleted and, if not, it can undo partly completed transactions so thatthe integrity of data records is maintained. CICS products are providedfor OS/390, UNIX, and Intel PC operating systems. CICS also allows endusers to use IBM's Transaction Server to handle e-business transactionsfrom Internet users and forward these to a mainframe server thataccesses an existing CICS order and inventory database.

[0069] “IMS” (Information Management System) is the system from IBMthat, together with IBM's Enterprise Systems Architecture (IMS/ESA)provides a transaction manager and a hierarchical database server.

[0070] “MQ” is the MQSeries IBM software family whose components areused to tie together other software applications so that they can worktogether. This type of application is often known as businessintegration software or middleware. Functionally, MQSeries provides acommunication mechanism between applications on different platforms, anintegrator which centralizes and applies business operations rules, anda workflow manager which enables the capture, visualization, andautomation of business processes. MQSeries connects different computersystems, at diverse geographical locations, using dissimilar ITinfrastructures, so that a seamless operation can be run. IBM's MQSeriessupplies communications between applications, and between users and aset of applications on dissimilar systems. Additionally, MQSeries'messaging scheme requires the application that receives a message toconfirm receipt. If no confirmation materializes, the message is resentby the MQSeries.

[0071] “Rose” is an object-oriented Unified Modeling Language (UML)software design tool intended for visual modeling and componentconstruction of enterprise-level software applications. It enables asoftware designer to visually create (model) the framework for anapplication by blocking out classes with actors (stick figures), usecase elements (ovals), objects (rectangles) and messages/relationships(arrows) in a sequence diagram using drag-and-drop symbols. Rosedocuments the diagram as it is being constructed and then generates codein the designer's choice of C++, Visual Basic, Java, Oracle8, Corba orData Definition Language.

[0072] Common Application Metamodel Overview.

[0073] The Common Application Metamodel (CAM) brings interconnectivityto the environment illustrated in FIG. 1. FIG. 1 illustrates a typicalsystem 101 with multiple application components, including a NetscapeInternet Explorer browser 103, Net.Commerce 105 on a Sun Solaris server107, Oracle 109 and DB2 111 on a database server 113, SAP 115 running onAIX 117, a CICS 390 server 119, an IMS 390 server 121, DB2 123 and DL/I125 on a S/390 platform 127, a Windows 2000 client 129, and Baan 131running on an HP Unix server 133. The Common Application Metamodel (CAM)is metadata interchange method, tool, and system for marshaling andapplying information needed for accessing enterprise applications, suchas in FIG. 1, in a source language and converting them to a targetlanguage. CAM consists of language metamodels and application domaininterface metamodels, as shown in FIG. 2, which illustrates the roles ofmessage sets 203, SQL stored procedures 205, legacy applications 207,and programming languages 209 as inputs to the metadata repository 211of the Common Application Metamodel to facilitate enterprise applicationintegration 221.

[0074] Exemplary metamodels include C, C++, Java, COBOL, PL/I, HLAssembler, IMS transaction messages, IMS MFS, CICS BMS, and MQSeriesmessages models, as shown in FIG. 3, which illustrates the CommonApplication Metamodel of the invention, with an invocation metamodel301, an application-domain interface metamodel 303, and a languagemetamodel 305.

[0075]FIG. 4 illustrates an IMS OTMA application interface metamodel411, with an OTMA Invocation Metamodel 421, an IMS Transaction MessageMetamodel 423, a COBOL Metamodel 425, and a C Metamodel 427.

[0076]FIG. 5 illustrates the flow of information from an existingapplication 501, through an interface 503 to an object model containingapplication interface metadata. This application interface metamodel isstored in the metadata repository 505, and, at an appropriate time,retrieved from the metadata repository 505, combined with a sourceprogram 507 in a generation tool 509, and used to generate a target file511, as an XML file, i.e., an XMI instance file. CAM is highly reusableand independent of any particular tool or middleware.

[0077] Development Stage. With CAM, tooling can now easily providesolutions to access enterprise applications, e.g. IMS applications. Byparsing each source file and generating XML documents based on the CAMmodel, COBOL copybook, PL/I copybook, MFS Source, BMS Source, etc.,tools can provide connector solutions to IMS, and CICS, etc.

[0078] In this regard, FIG. 6 illustrates a development phase scenariowhere a Common Application Metamodel Rose file 601, e.g., a COBOLmetamodel, a PL/I metamodel, an MFS metamodel, a BMS model, or the likeis read into a toolkit 603, to generate a DTD and schema for a Rosemodel and Java code for a Rose model 605. A source file of anapplication 607, as a COBOL source file, a PL/I source file, an MFSsource file, a BMS source file, or the like, and the Java code for theRose model 609 are read into an Importer 611. The importer parses thesource code and provides, as output, an XMI instance file 613, i.e., XMLdocuments, of the application source files.

[0079]FIG. 7 shows a CAM metamodel for application interfaces. ThisFigure depicts a runtime connector 701 with invocation andtransformation capabilities, interfacing with an existing applicationprogram 703 through an interface 705 containing the existing applicationprogram's interface definition, in accordance with the applicationinterface metamodel 707. The Application Interface metadata is stored ina metadata repository 709.

[0080] The flow and messaging middleware 713 invokes applications 703through the application interfaces 705. These interfaces 705 are theaccess points to the applications 703 through which all input and outputis connected to the middleware 713. The interfaces 705 are described interms of the Application Interface Metamodel.

[0081] Transformation processing according to the metamodel could takeplace in source/client applications, target applications, or a gateway.

[0082] Because CAM also provides physical representation of data typesand storage mapping to support data transformation in an enterpriseapplication integration environment, it enables Web services forenterprise applications.

[0083] At development time CAM captures information that facilitates:

[0084] a). connector and/or connector-builder tools,

[0085] b). data driven impact analysis for application productivity andquality assurance, and

[0086] c). viewing of programming language data declarations bydevelopers.

[0087] The CAM metamodel files are inputs to toolkits used to generateDTD files, XML schemas, and Java classes which represent the CAM model.Importers parse each source file (e.g. COBOL or PL/I copybook, MFSsource, and BMS, etc.), and then generate XML documents (i.e. XMLinstance files) based on Java classes generated by the XMI/MOF2 toolkit.

[0088] Run Time.

[0089] At run time CAM provides information which facilitatestransformation in an enterprise application integration environmentwhere it provides data type mapping between mixed languages, facilitatesdata translations from one language and platform domain into another.

[0090]FIG. 8 illustrates the application of the Common ApplicationMetamodel during run time. As shown, SOAP compliant XML documents 803are received in, for example, IBM WebSphere middleware, 805, whichcontains an IMSConnector for Java 807, and is in contact with an XMLRepository 809, containing the XMI instance files for the CAM model. TheIBM WebSphere middleware sends the transformed file to the IMS system811, which contains an instance of IMS Connect 813 and the IMStransactional application program 815. CAM facilitates connectivitybetween the back-end IMS application 815 and the Web file (e.g., SOAPcompliant XML documents) 803. The CAM accomplishes this by using CAMmodel information (from repository 809) to perform data transformationsfrom one platform to another in the mixed language environment shown.

[0091] Type Descriptor Metamodel.

[0092] One important feature provided by CAM is the Type Descriptormetamodel. The Type Descriptor metamodel defines the physicalrealization, storage mapping, and the constraints on the realization(such as justification). This metamodel provides a physicalrepresentation of individual fields of a given data structure. Whensupporting data transformation in an enterprise application integrationenvironment, the model provides data type mapping between mixedlanguages. It also facilitates data translations from one language andplatform domain into another. The metamodel is used for runtime datatransformation (or marshaling) with a language-specific metamodel foroverall data structures and field names.

[0093] 1. Common Application Metamodel for Application Interfaces

[0094] The interconnection of disparate and dissimilar applicationsrunning on different software platforms, as shown in FIG. 1, withdifferent operating systems, physical platforms, and physicalrealizations is accomplished through connectors that incorporate theinterconnection metadata. Connectors are a central part of theapplication framework for e-business. The end user demand is to connectto anything interesting as quickly, and as easily, as possible.

[0095] A connector is required to match the interface requirements ofthe adapter and the legacy application. It is also required to mapbetween the two interfaces. Standardized metamodels for applicationinterfaces presented herein allow reuse of information in multipleconnector tools. These standardized metamodels not only reduce work tocreate a connector, but also reduce work needed to develop connectorbuilder tools.

[0096] The connectors built using the common application metamodel ofour invention provide interoperability with existing applications. Theconnectors support leveraging and reuse of data and business logic heldwithin existing application systems. The job of a connector is toconnect from one application system server “interface” to another.Therefore, an application-domain interface metamodel describessignatures for input and output parameters and return types for a givenapplication system domain (e.g. IMS, MQSeries); it is not for aparticular IMS or MQSeries application program. The metamodel containsboth syntactic and semantic interface metadata.

[0097] 1.a. End-to-End Connector Usage Using Common ApplicationMetamodel

[0098] The Common Application Metamodel (CAM) consists ofmeta-definitions of message signatures, independent of any particulartool or middleware. Different connector builder tools can use thisinformation to ensure the “handshaking” between these applicationprograms, across different tools, languages, and middleware. Forexample, if you have to invoke a MQSeries application, you would need tobuild a MQ message using data from a GUI tool and deliver it using theMQ API. Similarly, when you receive a message from the MQSeriesapplication, you would need to get the buffer from MQSeries, parse itand then put it into a GUI tool data structure. These functions can bedesigned and implemented efficiently by a connector builder tool usingCAM as standardized metamodels for application interfaces.

[0099] CAM can be populated from many sources, including copy books, togenerate HTML forms and JavaServer Page (JSP) for gathering inputs andreturning outputs. An example of a connector as depicted in the previousfigure is that the flow and message middleware makes a function call toan enterprise application by calling the connector which then calls theenterprise application API. The connector does language and data typemappings, for example, to translate between XML documents and COBOLinput and output data structures based on CAM. Connectors and CAMprovide the end-to-end integration between the middleware and theenterprise applications.

[0100] Using IMS as an example. Let's say that you must pass an accountnumber to an IMS transaction application program from your desktop towithdraw $50.00. With CAM and a connector builder tool, you will firstgenerate an input HTML form and an output JSP; and develop a middlewarecode necessary to support the request. The desktop application fills therequest data structure (i.e. an input HTML form) with values and callsthe middleware. The middleware service code will take the data from theGUI tool, build an IMS Connect XML-formatted message, and deliver themessage to the IMS gateway (i.e. IMS Connect) via TCP/IP. IMS Connecttranslates between the XML documents and the MS message data structuresin COBOL using the metadata definitions captured in CAM. It then in turnsends the IMS message data structures to IMS via Open TransactionManager Access (OTMA). The IMS COBOL application program runs, andreturns the output message back to the middleware service code via IMSConnect. The middleware service code gets the message and populates theoutput JSP page (i.e. previously generated GUI tool reply datastructures) with the reply data. The transaction output data will thenbe presented to the user.

[0101] 2. Common Application Metamodel

[0102] CAM is used to describe information needed to easily integrateapplications developed in common programming models with other systems.The CAM metamodel can be used for both synchronous and asynchronousinvocations.

[0103] 2.a. Common Application Metamodel

[0104] The common application metamodel depicted as follows consists ofan invocation metamodel and an application-domain interface metamodelwhich uses language metamodels. For any given application-domaininterface metamodel, it may use one or many language metamodels, but,there could be zero or more invocation metamodels.

[0105] The common connector metamodel is illustrated in FIG. 3. It hasan Invocation Metamodel 301, an Application-Domain Interface Metamodel303, and a Language Metamodel 305.

[0106] 2.a.i. Invocation Metamodel

[0107] The invocation metamodel 301 consists of one or more of thefollowing possible metadata elements. However, for a particularinvocation, it could include only one or many of the following metadataelements.

[0108] Message-control information. This includes message controlinformation, such as the message connection name, message type, sequencenumbers (if any), and various flags and indicators for response,commit-confirmation, and processing options by which a client or servercan control message processing to be synchronous or asynchronous, etc.

[0109] The connection name can be used by the application system serverto associate all input and output with a particular client. The messagetype specifies that the message is a response message; or that commit iscomplete. It can also indicate server output data to the client, orclient input data to the server.

[0110] Security data—This includes authentication mechanism, andsecurity data, e.g. digital certificates, identity, user name andpassword, etc. It may also include authorization information to indicatewhether the data can be authorized via a role based or ACL (accesscontrol list) based authorization.

[0111] Transactional semantics—This will carry transaction information,e.g. local vs. global transaction; two-phase commit vs. one-phasecommit, and transaction context, etc.

[0112] Trace and debug—Trace and debugging information are specified aspart of the metamodel.

[0113] Precondition and post-condition resource—This describesapplication state precondition and post-condition relationships.

[0114] User data—This includes any special information required by theclient. It can contain any data.

[0115] 2.a.ii. Application-Domain Interface Metamodel Theapplication-domain interface metamodel 303, as discussed earlier,describes signatures for input and output parameters and return typesfor application system domains.

[0116] 2.a,iii. Language Metamodel

[0117] The language metamodel 305, e.g. COBOL metamodel, is used byenterprise application programs to define data structures (semantics)which represent connector interfaces. It is important to connector toolsto show a connector developer the source language, the target language,and the mapping between the two. The CAM language metamodel alsoincludes the declaration text in the model which is not editable (i.e.read-only model). Because the connector/adapter developer would probablyprefer to see the entire COBOL data declaration, including comments andany other documentation that would help him/her understand the businessrole played by each field in the declaration.

[0118] The language metamodel is also to support data driven impactanalysis for application productivity and quality assurance. (But, it isnot the intention of the CAM to support reproduction of copybooks.) Thelanguage metamodels describing connector data are listed as follows:

[0119] C

[0120] C++

[0121] COBOL

[0122] PL/I

[0123] 2.a.iv. Type Descriptor Metamodel

[0124] The Type Descriptor metamodel is language neutral and defines thephysical realization, storage mapping and the constraints on therealization such as justification. This metamodel provides physicalrepresentation of individual fields of a given data structure. The typedescriptor metamodel is to support data transformation in an enterpriseapplication integration environment to provide data types mappingbetween mix languages. It also facilitates data translations from onelanguage and platform domain into another. This metamodel will be usedas a recipe for runtime data transformation (or marshaling) withlanguage specific metamodel for overall data structures and fieldsnames.

[0125] 3. An Example of Common Connector Metamodel

[0126] IMS OTMA (Open Transaction Manager Access) is atransaction-based, connectionless client/server protocol within anOS/390 sysplex environment. An IMS OTMA transaction message consists ofan OTMA prefix, plus message segments for input and output requests.Both input and output message segments contain llzz (i.e. length of thesegment and reserved field), and application data. Only the very firstinput message segment will contain transaction code in front of theapplication data. IMS transaction application programs can be written ina variety of languages, e.g. COBOL, PL/I, C, and Java, etc. Therefore,the application data can be in any one of these languages.

[0127] As shown in FIG. 4, an IMS OTMA connector metamodel 401 iscomposed of an invocation metamodel 403 and an IMS transaction messagemetamodel 405, as well as a COBOL metamodel 407 and a C metamodel 409.As depicted in FIG. 4, the invocation metamodel 401 is the OTMA prefix,and the IMS transaction message metamodel 405 is the application-domaininterface metamodel for the IMS application system which uses languagemetamodels. Metamodels for COBOL 407 and C 409 are shown.

[0128] 4. Type Descriptor Metamodel

[0129] The type descriptor metamodel presents a language and platformindependent way of describing implementation types, including arrays andstructured types. This information is needed for marshaling and forconnectors, which have to transform data from one language and platformdomain into another. Inspections of the type model for differentlanguages can determine the conformance possibilities for the languagetypes. For example, a long type in Java is often identical to a binarytype (computational-5) in COBOL, and if so, the types may beinter-converted without side effect. On the other hand, an alphanumerictype in COBOL is fixed in size and if mapped to a Java type, loses thisproperty. When converted back from Java to COBOL, the COBOL truncationrules may not apply, resulting in computation anomalies. In addition,tools that mix languages in a server environment (e.g., Java and COBOLin CICS and IMS) should find it useful as a way to determine howfaithfully one language can represent the types of another.

[0130] Therefore, an instance of the type descriptor metamodel describesthe physical representation of a specific data type for a particularplatform and compiler.

[0131] 4.a. TDLang Metamodel

[0132] The TDLang metamodel serves as base classes to CAM languagemetamodels by providing a layer of abstraction between the TypeDescriptor metamodel and any CAM language metamodel. All TDLang classesare abstract and common to all the CAM language metamodels. Allassociations between TDLang classes are marked as “volatile,”“transient,” or “derived” to reflect that the association is derivedfrom the language metamodel. The TDLang model does not provide anyfunction on its own, but it is the type target for the association fromthe Type Descriptor metamodel to the language metamodels.

[0133]FIG. 9 illustrates the structure of the TDLang Metamodel, with theTDLangClassifier 501, the TDLangComposedType 503 and the TDLangElement505.

[0134] With the TDLang base classes, the Type Descriptor metamodel canbe used as a recipe for runtime data transformation (or marshaling) withthe language-specific metamodel for overall data structures and fieldnames, without duplicating the aggregation associations present in thelanguage model.

[0135] 4.b. Type Descriptor Metamodel

[0136] This metamodel is a MOF Class instance at the M2 level. FIG. 10shows the relationships within the type descriptor Metamodel, includingthe PlatformCompilerType 601, the InstanceTDBase 603, the ArrayTD 605,the AggregatelnstanceTD 607, the Simple InstanceTD 609, and theInstanceType 611. The InstanceType 611 comprises definitions of theStringTD 613, the AddressTD 615, the NumberTD 617, and the FloatTD 619.FIG. 11 illustrates a higher level view of the TDLanguageElement and thePlatformCompilerType 601. FIG. 12 illustrates enumerations of signCoding801, lengthEncoding 803, floatType 805, accessor 807, packedDecimalSign809, and bitModePad 811.

[0137] 4.c. Type Descriptor and Language Models

[0138] The Type Descriptor model is attached to the CAM Language modelby a navigable association between TDLangElement and InstanceTDBase.TDLangElement is the base language model type used to represent adeclared data item, i.e., an instance of a type. InstanceTDBase is thebase Type Descriptor model type used to represent theimplementation-specific instance of this same declared data item.InstanceTDBase is abstract; only one of its subtypes may beinstantiated.

[0139] It is possible that a data item declared in a programminglanguage may have different implementations. These differences areinduced by hardware platform, system platform, and compiler differences.This possibility is modeled by the PlatformCompilerType model type. Theassociation between TDLangElement and PlatformCompilerType is many toone, and the association between PlatformCompilerType and InstanceTDBaseis one to one. To navigate from the language model, it is necessary toknow what PlatformCompilerType is to be assumed. It is possible that animplementation, upon importing a model instance, will wish to removefrom the model the PlatformCompilerType instances that are not ofinterest.

[0140] The association between TDLangElement and InstanceTDBase ismodeled in this manner to allow for extending the model to include anassociation between PlatformCompilerType and a new type that more fullydescribes the hardware platform, the system platform, and the compiler.

[0141] Data element instances may be defined as repeating groups orarrays. This is modeled as a one to many association betweenInstanceTDBase and the ArrayTD model type. There would be one ArrayTDinstance in this association for each dimension, subscript, orindependent index of the data element. These instances hold informationabout the bounds and accessing computations.

[0142] The association is ordered in the same order as the correspondingassociation in the language model, and reflects the syntactic orderingof the indices as defined by the programming language. The rationale forthis choice is the resulting equivalence of navigation and processingalgorithms between the language model and the Type Descriptor model.Another choice, perhaps more advantageous to marshaling engines, wouldbe to have the ordering of the indices from the smallest stride to thelargest. This allows a marshaling engine to process the array in itsnatural storage order, assuming it is laid out in the usual contiguousfashion. A marshaling engine can compute this order by re-sorting theassociation targets according to the stride formulas if desired.

[0143] Array information may be a complex property of the data elementor of its type, and various languages and programming practices seem tofall on either side. The typedef facility of C and C++ allows thedefinition of some array types from typedefs, but only where the arraydefinitions are applied to the topmost elements of typedef aggregates.For example, consider the following typedef: typedefstruct { intA;struct { int C; char D; struct { int F; int G; }E; }B; }X;

[0144] This typedef can be used to create a new typedef for a fixed sizearray, e.g.

[0145] typedef X Q[10];

[0146] But it is not possible to create a new typedef from X that makesany of the subcomponents of X, e.g., D or E, into an array. This exampleand many others point out the unclear status of array definitions intyped languages.

[0147] An InstanceTDBase type has two concrete subtypes,SimplelnstanceTD and AggregatelnstanceTD. SimplelnstanceTD models dataelements without subcomponents, while AggregatelnstanceTD models dataelements with subcomponents. To find the subcomponents of anAggregatelnstanceTD, one must navigate back to the corresponding dataelement declaration in the CAM language model. There, the associationbetween an aggregate type and its subcomponents may be navigated,leading to a set of subcomponent data elements, each of which has one ormore corresponding instances in the Type Descriptor model. Thisintroduces some model navigation complexity, but avoids duplicating theaggregation hierarchy in both the language and the Type Descriptormodels. The additional processing complexity of traversal is not great,and considerable simplification is obtained in algorithms that wouldmodify the model to add, delete or rearrange subcomponents in anaggregation.

[0148] A SimplelnstanceTD model type is also associated one to one witha BaseTD model type. The BaseTD model type is specialized to holdimplementation information that is common for all data elements of thesame language type. The information that describes a 32-bit signedbinary integer on a specific hardware/software platform is thusinstantiated only once in a given model instantiation, no matter howmany data elements may be declared with this type.

[0149] One may contemplate an association between TDLangClassifier andBaseTD matching the association between TDLangElement andInstanceTDBase. However, this is problematic in that constructions thatthe language regards as simple types (e.g., strings) may not mapdirectly to simple hardware/software types. Rather than introduce moremechanisms into the Type Descriptor model to describe stringimplementations, a specialization of BaseTD is utilized which describesthe common string implementations. Various attributes in theTypeDescriptor model are suffixed with the string “formula.” Theseattributes contain information that may in some cases be impossible tocompute without access to data created only at run-time. An example isthe current upper bound of a variable-sized array or the offset to anelement that follows another element whose size is only known atrun-time. Such information could be included as values in a modelinstance, but this would require a model instance for each run-timeinstance, and would mean that the model could only be constructed atrun-time, requiring the model definition to include factories and otherapparatus to create model instances at run-time. A model that can beconstructed from platform and compiler knowledge is much more useful,and the formulas provide a way to define concrete values when therun-time information is available. These formulas may be interpreted bymarshaling engines, or they may be used to generate marshaling code,which is loaded and executed by the marshaling engine on demand.

[0150] 4.d. Formulas

[0151] As used in connection with formulas, “field” refers to acomponent of a language data structure described by the Type Descriptormodel, while “attribute” denotes part of the model, and has a valuerepresenting a “property” of the field. Thus the value of a field meansa run-time value in a particular instance of a language data structure,whereas the value of an attribute is part of the description of a fieldin a language data structure, applies to all instances of the datastructure, and is determined when the data structure is modeled.

[0152] For most attributes in an instance of the Type Descriptor model,the value of the attribute is known when the instance is built, becausethe properties of the fields being described, such as size and offsetwithin the data structure, are invariant. But if a field in a datastructure is defined using the COBOL OCCURS DEPENDING ON construct orthe PL/I Refer construct, then some properties of the field (andproperties of other fields that depend on that field's value) cannot bedetermined when the model instance is built.

[0153] Properties that can be defined using these language constructsare string lengths and array bounds. A property that could indirectlydepend on these language constructs is the offset of a field within astructure, if the field follows a variable-size field.

[0154] In order to handle these language constructs, properties of afield that could depend on these constructs (and thus the values of thecorresponding attributes), are defined with strings that specify aformula that can be evaluated when the model is used.

[0155] However, if a property of a field is known when the modelinstance is built, then the attribute formula simply specifies aninteger value. For example, if a string has length 17, then the formulafor its length is “17”.

[0156] The formulas mentioned above are limited to the following:

[0157] Unsigned integers

[0158] The following arithmetic integer functions neg(x) := x // prefixnegate add(x,y) := x + y // infix add sub(x,y) := x − y // infixsubtract mpy(x,v) := x*y // infix multiply div(x,y) := x/y // infixdivide max(x,y) := max(x,y) min(x,y) := =min(x,y) mod(x,v) := x mod y

[0159] The mod function is defined as mod(x,y)=r where r is the smallestnon-negative integer such that x−r is evenly divisible by y. So mod(7,4)is 3, but mod(−7,4) is 1. If y is a power of 2, then mod(x,y) is equalto the bitwise-and of x and y−1.

[0160] The val function

[0161] The val function returns the value of a field described by themodel. The val function takes one or more arguments, and the firstargument refers to the level-1 data structure containing the field, andmust be either:

[0162] the name of a level-1 data structure in the language model

[0163] the integer 1, indicating the level-1 parent of the variable-sizefield. In this case, the variable-size field and the field thatspecifies its size are in the same data structure, and so have a commonlevel-1 parent.

[0164] The subsequent arguments are integers that the specify theordinal number within its substructure of the (sub)field that should bedereferenced.

[0165] By default, COBOL data fields within a structure are not alignedon type-specific boundaries in storage. For example, the “natural”alignment for a four-byte integer is a full-word storage boundary. Suchalignment can be specified by using the SYNCHRONIZED clause on thedeclaration. Otherwise, data fields start immediately after the end ofthe preceding field in the structure. Since COBOL does not have bitdata, fields always start on a whole byte boundary.

[0166] 4.d.i) Formula Examples for COBOL

[0167] The examples use the proposed inline comment indicator “*>” fromthe draft standard. It is not yet legal COBOL usage.

[0168] 1. Consider the following data description: *>Field Offset 01Used-Car. *>“0” 02 Summary. *>“0” 03 Make pic x(36). *>“0” 03 Model picx(44). *>“36” 03 VINpicx(13). *>“80” 03 Color pic x(10). *>“93” 88 Redvalue ‘Red’. 88 White value ‘White’. 88 Blue value ‘Blue’. 02 History.*>“103” 03 Mileage pic 9(6). *>“103” 03 NumClaims binary pic 9. *>“109”03 InsCode pic x. *>“111” 03 Claims. *>“112” 04 Claim occurs 1 to 9times depending on NumClaims. *>stride(1) = “157” 05 ClaimNo pic x(12).05 ClaimAmt binary pic 9(5). 05 Insurer pic x(38). 05 Details picx(100). 02 Price comp pic 9(5)v99. *>“add(112,mpy(val(1,2,2),157))”

[0169] The offset of Model is straightforward, and is given by theformula “36”. So is that of Claims, which is “112”.

[0170] But because the array Claim can occur a variable number of times,the structure History is a variable-size field. Thus the offset ofPrice, which immediately follows Claims, requires a more complicatedformula, involving the array stride (the distance between successiveelements along a specific dimension). For Claim, there is only onedimension, and the formula for its stride is “154”. Thus the formula forthe offset of Price is:

[0171] “add(112, mpy(val(1,2,2),154))”

[0172] The first argument of the val function is 1, meaning that thefield containing the value at run-time, NumClaims, is in the samelevel-1 structure, Used-Car, as the field, Price, whose offset isspecified by the formula. The other two arguments are 2 and 2. The first2 refers to the second immediate subcomponent, History, of Used-Car. Thesecond 2 means that the field to be dereferenced is the second componentof History, that is, NumClaims.

[0173] If the OCCURS DEPENDING ON object were in a separate structure,the third subcomponent of level-1 structure Car-Data, say, then the valfunction would be “val(Car-Data,3)”.

[0174] COBOL structure mapping is top-down, although the directiondoesn't make any difference unless the SYNCHRONIZED clause is specifiedon the data declaration. Specifying SYNCHRONIZED forces alignment ofindividual fields on their natural boundaries, and thus introduces“gaps” into the structure mapping. Consider the following datastructure, which is identical to the previous example, except for theSYNCHRONIZED clause: *>Field Offset 01 Used-Car SYNCHRONIZED *>“0” 02Summary. *>“0” 03 Make pic x(36). *>“0” 03 Model pic x(44). *>“36” 03VINpicx(13). *>“80” 03 Color pic x(10). *>“93” 88 Red value ‘Red’. 88White value ‘White’. 88 Blue value ‘Blue’. 02 History. *>“103” 03Mileage pic 9(6). *>“103” 03 NumClaims binary pic 9. *>“110” 03 InsCodepic x. *>“112” 03 Claims. *>“113” 04 Claim occurs 1 to 9 times dependingon Num Claims. *>stride(1) = “160” 05 ClaimNo pic x(14). 05 ClaimAmtbinary pic 9(5). 05 Insurer pic x(39). 05 Details pic x(100). 02 Pricecomp pic 9(5)v99. *> “add(add(113, mpy(val(1,2,2),160)), 3)”

[0175] To position the binary fields on their appropriate half-word orfull-word storage boundaries, COBOL introduces padding, known as “slackbytes”, into the structure. Working top-down, this padding is introducedimmediately before the field needing alignment. So there is one byte ofpadding between Mileage and NumClaims.

[0176] For an array, such as Claim, COBOL not only adjusts the paddingwithin an element, but also the alignment of each element of the array.In the example, the first occurrence of Claim starts one byte past afull-word boundary. Because the field ClaimNo is an exact number offull-words long, it ends one byte past a full-word boundary, so COBOLinserts three bytes of padding immediately before the binary full-wordinteger ClaimAmt. And to align subsequent occurrences, so that they toostart one byte past a full-word boundary like the first, and can thushave an identical configuration, COBOL adds three bytes of padding atthe end of each occurrence.

[0177] Finally, after padding, each occurrence of Claim (starts and)ends one byte past a full-word boundary, so COBOL puts three bytes ofpadding before the binary field Price. As a result of all these extrabytes, the formula for the offset of Price has changed considerably fromthe unaligned example, and is now: “add(add(113,mpy(val(1,2,2),160)),3)”

[0178] There are several differences between the OCCURS DEPENDING ONconstruct and PL/I's Refer option. Storage for COBOL structures isalways allocated at the maximum size, whereas PL/I structures areallocated at the actual size specified by the Refer option. It is legaland usual to change the number of occurrences in a particular instanceof a variable-size COBOL array, and this has the effect of changing thelocation and offset of any fields that follow the array. For PL/I, thevalue of the Refer object of a particular instance of a structure isintended to be fixed during execution Thus aligned objects following avariable-size field are always correctly aligned for each instance ofthe structure, because the amount of padding is computed uniquely foreach instance, as determined by the Refer option. By contrast, theamount of padding for any aligned fields following a variable-size COBOLarray is computed assuming the maximum array size, and is fixed atcompile time. If the array is smaller than its maximum size, then thealignment will typically be incorrect. For instance in this example: 1 async. 2 b binary pic 9. 2 c pic x occurs 1 to 5 times depending on b. 2d binary pic 9(9).

[0179] COBOL inserts one byte between c and d. The alignment of d istherefore correct for only two values of b, the maximum, 5, and 2.

[0180] As noted above, the formulas describe not only offsets of fieldswithin a structure, but also properties of arrays, such as bounds andstrides. COBOL does not have true multi-dimensional arrays, althoughelement references do use multiple subscripts. Instead, COBOL has arraysof arrays, as in the following simple example: 1 a. *<offset “0” 2 d1occurs 5 times. *<offset = “0” *<lbound(1) = “1” *<hbound(1) = “5”*<stride(1) = “168” 3 d2 occurs 6 times. *<offset = “0” *<lbound(2) =“1” *<hbound(2) = “6” *<stride(2) = “28” 4 e1 binary pic 9(9) occurs 7times. *<offset = “0” *<lbound(3) “7” *<hbound(3) = “7” *<stride(3) =“4”

[0181] The program can refer to slices of the array by subscripting thehigher-level container fields, for example, d1(2) or d2(3, 4), but thenormal kind of reference is to the low-level elements using the fullsequence of subscripts, for instance, el(4, 5, 6). To locate elementel(m, n, o) using these stride formulas, one would take the address of aand add to it (m−1)*168+(n−1)*28+(o−1)*4. For COBOL, the lower bound ofan array subscript is always 1. That is, the first element is alwayselement(l), and vice versa.

[0182] Needless to say, any dimension of the array can have the OCCURSDEPENDING ON clause, and the array can be followed by other fields,which complicates the formulas a lot. Consider the example: 1 a. 2 x1binary pic 9. *<offset = “0” 2 x2 binary pic 9. *<offset = “2” 2 x3binary pic 9. *<offset = “4” 2 d1 occurs 1 to 5 times *<offset = “6”depending on x1. *<lbound(1) = “1” *<hbound(1) = “val(1,1)” *<stride(1)= “mpy(val(1,2),mpy(val(1,3),4))” 3 d2 occurs 1 to 6 times *<offset =“6” depending on x2. *<lbound(2) = “1” *<hbound(2) = “val(1,2)”*<stride(2) = “mpy(val(1,3),4)” 4 e1 binary pic 9(9) *<offset = “6”occurs 1 to 7 times *<lbound(3) = “1” depending on x3. *<hbound(3) =“val(1,3)” *<stride(3) = “4” 2 b binary pic 9(5). *<offset = “seebelow!”

[0183] Computing the address of a particular element still involves thestride formulas, but these are no longer simple integers. The address ofelement el(m, n, o) in the above example is given by taking the addressof a and adding to it:

(m−1)*stride(1)+(n−1)*stride(2)+(o−1)*stride(3), i.e.,

(m−1)*4*val(1,3)*val(1,2)+(n−1)*4*val(1,3)+(o−1)*4.

[0184] Similarly, these stride formulas are used in the formula for theoffset of b:

“add(6, mpy(val(1,1), mpy(val(1,2), mpy(4,val(, 3)))))

[0185] 4.e. Type Descriptor Specification

[0186] 4.e.i. TDLang Metamodel Specification

[0187] TDLang Classes—General Overview.

[0188] TDLang classes serve as a layer of abstraction between any CAMlanguage model and the TypeDescriptor model.

[0189] Since any CAM language model can plug into the TDLang model, theType Descriptor model only needs to understand how to interface withTDLang in order to access any CAM language model.

[0190] The TDLang model does not provide any function on its own andtherefore only makes sense when it is attached to a language model.TDLang is common to all the CAM language models and is the type targetfor the association from TypeDescriptors to the language models.

[0191] Note all TDLang classes are abstract and they serve as the baseclasses to the language metamodels.

[0192] TDLangClassifier.

[0193] TDLangClassifier is the parent class of all language-specificClassifier classes and TDLangComposedType. The TDLangSharedTypeassociation is derived from the language's “+sharedType” associationfrom Element to Classifer class. The association should be marked“volatile,” “transient,” or “derived” to reflect that the association isderived from the language model. The TDLangClassifier is derived fromTDLangModelElement.

[0194] TDLangElement.

[0195] TDLangElement is the parent class of all language-specificElement classes. The tdLangTypedElement association is derived from thelanguage's “+typedElement” association from Classifer to Element class.The association should be marked “volatile”, “transient”, and “derived”to reflect that the association is derived from the language model.

[0196] The tdLangElement association is derived from the language's“+element” association from Classifer to Element class. The associationshould be marked “volatile,” “transient,” or “derived” to reflect thatthe association is derived from the language model.

[0197] TDLangComposedType.

[0198] The TDLangComposedType is the parent class of alllanguage-specific ComposedTypes. The TDLangGroup association is derivedfrom the language's “+group” association from Element to ComposedTypeclass. The association should be marked “volatile,” “transient,” or“derived” to reflect that the association is derived from the languagemodel. The TDLangComposedType is derived from TDLangClassifier.

[0199] 4.e.ii. Type Descriptor Metamodel Specification

[0200] The Type Descriptor package defines a model for describing thephysical implementation of a data item type. This model is languageneutral and can be used to describe the types of many languages.Inspections of the type model for different languages can determine theconformance possibilities for the language types. For example, a longtype in Java is often identical to a binary type in COBOL, and if so,the types may be interconverted without side effect. On the other hand,an alphanumeric type in COBOL is fixed in size and if mapped to a Javatype, will lose this property. When converted back from Java to COBOL,the COBOL truncation rules may not apply, resulting in computationanomalies.

[0201] AggregatelnstanceTD.

[0202] For each instance of an aggregate, there is an instance of thisclass. To find the children of this aggregate, one must navigate theassociations back to language Classifier then downcast to languageComposed Type and follow the association to its children.

[0203] Derived from InstanceTDBase

[0204] Public Attributes:

[0205] union: boolean=false

[0206] Distinguishes whether the aggregation is inclusive (e.g. astructure) or exclusive (e.g. a union).

[0207] If union=true, storage might be overlaid and as a result theinterpretation of the content may be uncertain.

[0208] ArrayTD.

[0209] ArrayTD holds information for array types.

[0210] Public Attributes:

[0211] arraryAlign: int

[0212] Alignment requirements in addressible units for each element inthe array.

[0213] strideFormula: string

[0214] A formula that can be used to calculate the displacement addressof any element in the array, given an index.

[0215] strideInBit: boolean

[0216] True indicates strideFormula value in bits

[0217] False indicates strideFormula value in bytes

[0218] upperBoundFormula:String

[0219] Declared as a String for instances when this value is referencedby a variable.

[0220] This attribute supplies the upperbound value of a variable sizearray

[0221] Upperbound is required when traversing back up the entirestructure.

[0222] lowerBoundFormula: String

[0223] Declared as a String for instances when this value is referencedby a variable.

[0224] This attribute supplies the lowerbound value of a variable sizearray.

[0225] InstanceTDBase.

[0226] InstanceTD has instances for each declared variable and structureelement.

[0227] To find the parent of any instance (if it has one) one mustnavigate the associations back to TDLangElement, follow the associationto TDLangClassifier to locate the parent, then follow the associationsback into the TypeDescriptor model.

[0228] Public Attributes:

[0229] offsetFormula : string

[0230] A formula for calculating the offset to the start of thisinstance.

[0231] This attribute is String because this field may not always be aninteger value. For example, (value(n)+4) could be a possible value.

[0232] NOTE: The offset value is calculated from the top-most parent.(e.g., for a binary tree A→B, A→C, B→D, B→E. The offset to D iscalculated from A to D, not B to D)

[0233] contentSizeFormula: string

[0234] Formula for calculating the current size of the contents

[0235] allocSizeFormula: string

[0236] Formula for calculating the allocated size of the instance

[0237] formulaInBit: boolean

[0238] True indicates offsetFormula, contentSizeFormula, andallocSizeFormula values are in bits

[0239] False indicates offsetFormula, contentSizeFormula, andallocSizeFormula values are in bytes

[0240] defaultEncoding: String

[0241] Physical encoding—how many bits used to encode code points, howare the code points mapped onto bit patterns

[0242] Contains info on how string content is encoded: EBCDIC, ASCII,UNICODE, UTF-8, UTF-16, codepage numbers, etc. . . .

[0243] accessor: enumeration

[0244] Specifies access-rights for this element.

[0245] defaultBigEndian: boolean

[0246] True if this element is Big Endian format.

[0247] floatType: enumeration

[0248] Specifies this element's float type.

[0249] PlatformCompilerType.

[0250] A specific data type for a particular platform and compiler.NOTE: There needs to be some way to identify the platform and compiler.This class can be specializedor have an attribute, or be simplified byputting an attribute on InstanceTDBase.

[0251] Public Attributes:

[0252] platformCompilerType: String

[0253] This attribute specifies the type of compiler used to create thedata in the language model. Usage of this string is as follows:

[0254] “Vendor name, language, OS, hardware platform” (e.g., “IBM,COBOL, OS390, 390” or “IBM, PLI, WinNT, Intel”)

[0255] SimplelnstanceTD.

[0256] An instance of a Simple type in the language model.

[0257] Derived from InstanceTDBase

[0258] NumberTD

[0259] All numbers representations.

[0260] Currently includes Integers and Packed Decimals

[0261] Note required fields for these types of Numbers:

[0262] Integer

[0263] Base=2

[0264] MSBU=0 or 1

[0265] Signed/Unsigned

[0266] Size (in bytes)=1,2,4,8 (16)

[0267] Packed Decimal

[0268] Base=10

[0269] MSBU=0

[0270] Signed

[0271] Width=1-63

[0272] Float

[0273] Base=2(IEEE), 16(Hex)

[0274] MSBU=0 or 1

[0275] Signed

[0276] Size (in bytes)=4,8,16

[0277] Encoding Details . . .

[0278] Derived from BaseTD

[0279] Public Attributes:

[0280] base: int

[0281] The base representation of this number. 2=binary, 10=decimal,16=hex,

[0282] . . .

[0283] baseWidth: int

[0284] Number of bits used to represent base:

[0285] e.g. binary=1, decimal=8, packed=4

[0286] baseInAddr: int

[0287] Number of baseWidth units in addressable storage units—e.g.decimal=1, packed=2, binary=8 where the addressable unit is a byte. Ifthe addressable unit was a 32 bit word, decimal would be 4, packed wouldbe 8, and binary would be 32.

[0288] baseunits : int

[0289] Number of base units in the number. This times the base widthmust be less than or equal to the width times the addrUnit.

[0290] For example, a 24 bit address right aligned in a 32 bit wordwould have base=1, basewidth=24, baseInAddr=8, width=4.

[0291] signCoding : enumeration

[0292] A set of enumerations—2's complement, 1's complement, and signmagnitude for binary; zone signs for decimal, packed signs for packeddecimal, and unsigned binary, unsigned decimal.

[0293] checkValidity : boolean

[0294] True if language model is required for picture string support

[0295] packedDecimalSign : enumeration

[0296] Used to determine the code point of the sign in COBOL decimalnumbers, where the sign is combined with the leading or trailing numericdigit.

[0297] FloatTD

[0298] Floating points

[0299] Derived from BaseTD

[0300] Public Attributes:

[0301] floatType: enumeration

[0302] Specifies this element's float type.

[0303] 1 StringTD

[0304] Alphanumeric type

[0305] Derived from BaseTD

[0306] Public Attributes:

[0307] encoding: String

[0308] Physical encoding—how many bits used to encode code points, howare the code points mapped onto bit patterns

[0309] Contains info on how string content is encoded: EBCDIC, ASCII,UNICODE, UTF-8, UTF-16, codepage numbers, etc. . . .

[0310] lengthEncoding: enumeration

[0311] Possible values for lengthEncoding:

[0312] Fixed length (where total length equals declared string length)

[0313] Length prefixed (where total length equals declared string lengthplus length of header bytes; usually 1, 2, or 4 bytes)

[0314] Null terminated (known as varyingZ strings in PL/I) (where a nullsymbol is added to the end of string; so the maximum length could be upto declared string length plus one byte to represent null character)

[0315] maxLengthFormula: String

[0316] Formula specifying the maximum length of this string.

[0317] checkvalidity: boolean

[0318] True if language model is required for picture string support

[0319] textType: String=Implicit

[0320] Value is ‘Implicit’ or ‘Visual’

[0321] orientation: StringTD=LTR

[0322] Value is ‘LTR’, ‘RTL’, ‘Contextual LTR’, or ‘Contextual RTL’

[0323] where LTR=Left to Right

[0324] and RTL=Right to Left

[0325] Symmetric: boolean true

[0326] True if symmetric swapping is allowed

[0327] numeralShapes: String=Nominal

[0328] Value is ‘Nominal’, ‘National’, or ‘Contextual’

[0329] textShape: String=Nominal

[0330] Value is ‘Nominal’, ‘Shaped’, ‘Initial’, ‘Middle’, ‘Final’, or‘Isolated’

[0331] AddressTD

[0332] Type to represent pointers/addresses

[0333] Rationale for this class:

[0334] Addresses should be considered separate from NumberTD classbecause some languages on certain machines (e.g., IBM 400) representaddresses with additional information, such as permission type (which isnot represented in NumberTD class)

[0335] Derived From BaseTD

[0336] Public Attributes:

[0337] permission: String

[0338] Specifies the permission for this address. Used primarily forAS/400 systems.

[0339] bitModePad: enumeration

[0340] Specifies the number of bits for this address. Used to calculatepadding.

[0341] BaseTD

[0342] The base class of typeDescriptor.

[0343] The BaseTD model type is specialized to hold implementationinformation which is common for all data elements of the same languagetype. The information which describes a 32 bit signed binary integer ona specific hardware/software platform is thus instantiated only once ina given model instantiation, no matter how many data elements may bedeclared with this type.

[0344] Public Attributes:

[0345] addrUnit: enumeration

[0346] Number of bits in storage addressable unit

[0347] bit/byte/word/dword

[0348] width: int

[0349] Number of addressable storage units in the described type. Thiscan be 1, 8, 16, 32 bits.

[0350] alignment: int

[0351] Required alignment of type in address space—e.g. word aligned 32bit integer would have alignment of 4

[0352] nickname: int

[0353] Name of the base element. This should uniquely identify aninstance of a simple type to allow logic based on name rather than logicbased on combinations of attributes. E.g. “S390Binary31_(—)0” for a 32bit S/390 unsealed binary integer

[0354] bigEndian: boolean

[0355] True if this element is Big Endian format.

[0356] Stereotypes

[0357] bitModePad

[0358] Public Attributes:

[0359] 16 bit:

[0360] 24 bit:

[0361] 31 bit:

[0362] 32 bit:

[0363] 64 bit:

[0364] 128 bit:

[0365] signCoding

[0366] Note that this model does not include the following COBOL usages:

[0367] 1 POINTER

[0368] PROCEDURE-POINTER

[0369] OBJECT REFERENCE

[0370] Public Attributes:

[0371] twosComplement:

[0372] onesComplement:

[0373] signMagnitude:

[0374] zoneSigns:

[0375] packedSigns:

[0376] unsignedBinary:

[0377] unsignedDecimal:

[0378] lengthEncoding

[0379] Public Attributes:

[0380] fixedLength:

[0381] lengthPrefixed

[0382] nullTerminated:

[0383] floatType

[0384] Public Attributes:

[0385] Unspecified:

[0386] IEEEextendedlntel

[0387] For IEEE extended floats running on Intel Platform

[0388] IEEEextendedAIX:

[0389] For IEEE extended floats running on AIX Platform

[0390] IEEEextendedOS390:

[0391] For IEEE extended floats running on OS/390 Platform

[0392] IEEEextendedAS400:

[0393] For IEEE extended floats running on AS400 Platform

[0394] IEEEnonextended:

[0395] For IEEE non-extended floats

[0396] IBM390Hex:

[0397] For Hexadecimal floats running on IBM OS/390

[0398] IBM400Hex:

[0399] For Hexadecimal floats running on IBM AS400

[0400] accessor

[0401] Public Attributes:

[0402] ReadOnly:

[0403] WriteOnly:

[0404] ReadWrite

[0405] NoAccess

[0406] packedDecimalSign

[0407] Public Attributes:

[0408] MVS:

[0409] MVSCustom:

[0410] NT/OS2/AIX:

[0411] 5. COBOL Language Metamodels

[0412] The COBOL metamodel is used by enterprise application programs todefine data structures (semantics) which represent connector interfaces.

[0413]FIG. 13 illustrates a COBOL metamodel to define data structuresemantics which represent connector interfaces. This metamodel is also aMOF Class instance at the M2 level FIG. 14 illustrates the associationsbetween the COBOL metamodel with the TDLang base classes which are theTDLangClassifier, the TDLanguageComposedType, and the TDLangElement.

[0414]FIG. 15 illustrates an enumeration of the COBOL usage values inthe COBOL Metamodel.

[0415] The goal of this COBOL model is to capture the information thatwould be found in the Data Division. This model is intended to be usedonly as read-only to convert COBOL data division into it's XMLequivalent. This model is not intended to be used as a converter fromXML code into a COBOL data division equivalent. As a result,initialValues of elements are not captured in the model.

[0416] COBOLSimpleType

[0417] COBOLSimpleType is an abstract class that contains attributesshared by all simple types in the COBOL language.

[0418] Derived from COBOLClassifier

[0419] Public Attributes:

[0420] usage: COBOLUsageValues

[0421] Usage contains the data type as defined in COBOLUsageValues.

[0422] Usage defines the format of the data in memory. If none isspecified in the COBOL source, the default is “display”. Note that thepopular COMP-3 is equivalent to packed Decimal.

[0423] pictureString: String

[0424] This is a canonical form of the picture string specified in thesource. It is *not* necessarily identical to the picture string given inthe program!

[0425] Procedure to arrive at the canonical form of the picture string:

[0426] 1. Expand any parenthesized characters

[0427] 2. Construct parenthesized representation for any sequences ofidentical characters which are longer than 4 characters.

[0428] For example:

[0429] start with XXX999(3)

[0430] after step 1 you get: XXX99999

[0431] after step 2 you get: XXX9(5)

[0432] This canonical form yields the shortest equivalent picturestring. The canonical form is beneficial for equivalence checking.

[0433] Synchronized: Boolean=false

[0434] This boolean attribute corresponds to the SYNCHRONIZED or SYNCclause that may optionally be specified for an element.

[0435] Note that the COBOL language defines an additionalclause—RIGHT/LEFT—which may follow the SYNCHRONIZED clause.

[0436] However, IBM's implementation of COBOL does support thisadditional CLAUSE as documentation only—all elements defined asSYNCHRONIZED are automatically synchronized left.

[0437] Public Operations:

[0438] getCanonicalPictureString (pictureString: String): String Returnsthe condensed value of this string. For example, although thepictureString attribute may contain a picture string of 9999v99,getCanonicalPictureString( ) will return 9(4)v9(2) as the value.

[0439] COBOLElement

[0440] A COBOLElement represents every data definition in the COBOLprogram.

[0441] For example:

[0442] 01 EMPLOYEE

[0443] 03 SERIAL-NUMBER PIC 9(5).

[0444] 03 DEPARTMENT PIC (5).

[0445] EMPLOYEE, SERIAL-NUMBER, and DEPARTMENT are all COBOLElements.

[0446] Derived from TDLangElement

[0447] Public Attributes:

[0448] level: String

[0449] Level refers to the data number this element was declared in.redefined: Boolean=false

[0450] COBOLVariableLengthArray

[0451] A COBOLVariableLengthArray should be instantiated whenever thesource for a COBOLElement has the following syntax:

[0452] LEVEL ELEMENTNAME1 OCCURS X1 TO X2 TIMES DEPENDING ONELEMENTNAME2.

[0453] where X1 and X2 can be any integers 0 and higher and X2>X 1.ELEMENTNAME2 must be defined before ELEMENTNAME1.

[0454] COBOLVariableLengthArray has a single required association thatspecifies which element this array depends on.

[0455] Derived from COBOLFixedLengthArray

[0456] Public Attributes:

[0457] minUpper: Integer

[0458] In the case when maxUpper (max upper bound) belongs toVariableArray, maxUpper denotes the absolute upper bound of the arraythat can be allocated in memory. The actual maximum is denoted by thevalue of the element it refers to; which it gets by calling the“dependingon” association.

[0459] minUpper (minimum upper bound) is used to capture the COBOLsyntax that reads OCCURS 4 to 7 TIMES DEPENDING ON X1. In this case,minUpper equals 4 and maxUpper equals 7, and the actual upper bounddepends on the value of X1.

[0460] lower (lower bound) is always I (one) in the case of COBOL but isincluded for consistency with other languages and for clarity.

[0461] COBOLRedefiningElement

[0462] The REDEFINES clause allows you to use different data descriptionentries to describe the same computer storage area.

[0463] Example of this class in use: 1 TEST 2 Y PIC X(4) 2 YR REDEFINESY BINARY PIC 9(5) TypeDef = False for Redefine/UNION Derived fromCOBOLElement

[0464] COBOLComposedType

[0465] The COBOLComposedType class represents a nested declaration thatcontains additional elements. COBOLComposedType class is an aggregate ofCOBOLElements

[0466] COBOLComposedType is also the parent class of COBOLRedefines.

[0467] For example: 01 STUDENT. 05 CLASSES OCCURS 5. 10 CLASSNAME PICX(20). 10 CLASSNUM PIC 9(4).

[0468] STUDENT is defined by COBOLComposedElement. Its aggregation onlypoint to the CLASSES item, which is a COBOLElement. CLASSES is itselfdefined by a COBOLComposedElement.

[0469] Derived from COBOLClassifier, TDLangComposedType

[0470] COBOL88Element

[0471] COBOL88Element represents the COBOL 88 data level.

[0472] For example: TESTX PIC. 88 TRUEX VALUE ‘T’ ‘t’. *(TRUEX has 2values) 88 FALSEX VALUE ‘F’ ‘f’. *(FALSEX has 2 values)

[0473] Where TRUEX and FALSEX are condition names for the TESTX variableif value equals (‘T’ or ‘t’) or (‘F’ or ‘f’), respectively.

[0474] So if TESTX=‘T’ or ‘t’ then TRUEX=TRUE and FALSEX=FALSE;

[0475] If TESTX=‘F’ or ‘f’ then FALSEX=TRUE and TRUEX=FALSE;

[0476] Public Attributes:

[0477] name: String

[0478] Specifies the name or handle of the COBOL88Element.

[0479] COBOL88ElementValue

[0480] Example of this class in use: 1 TESTX PIC X.  88 TRUEX VALUE ‘T’‘t’. *(TRUEX has 2 values)  88 FALSEX VALUE ‘F’ ‘f’. *(FALSEX has 2values)  88 UA VALUE ‘A’ THRU ‘I’ ‘J’ THRU ‘R’ ‘S’ THRU ‘Z’ ‘&’ ‘-’.   *UA has 5 values; the first 3 are ranges

[0481] Rationale for this class:

[0482] This class exists because each COBOL88Element can contain morethan 1 value. For example, TRUEX contains 2 values, ‘T’ and ‘t’. Thusthis class can be instatiated more than once (but at least once) perCOBOL88Element (and thus the 1 . . . * cardinality)

[0483] For range values such as ‘A’ THRU ‘I’ in UA, lowerLimit=‘A’,upperLimit=‘I’, and range=true. Also note that when using the THRUkeyword, lowerLimit must be less than upperLimit.

[0484] For non-range values such as ‘T’ and ‘t’ we have decided that wewould use lowerLimit field to represent the value.

[0485] Public Attributes:

[0486] lowerLimit: String

[0487] lowerLimit refers to the lower bound of the THROUGH range

[0488] upperLimit: String

[0489] upperLimit refers to the upper bound of the THROUGH range

[0490] Range: Boolean

[0491] If range is set to true, literal-l must be less than literal-2,unless the associated data item is a windowed date field.

[0492] COBOLAlphaNumericType

[0493] The PICTURE character-string must consist of either of thefollowing:

[0494] The symbol

[0495] Combinations of the symbols A, X, and 9 (A character-stringcontaining all As or all 9s does not define an alphanumeric item.)

[0496] Other clauses: USAGE DISPLAY must be specified or implied.

[0497] Any associated VALUE clause must specify a nonnumeric literal ora figurative constant.

[0498] Derived from COBOLSimpleType

[0499] Public Attributes:

[0500] JustifyRight: Boolean=false

[0501] This boolean corresponds to the JUSTIFIED (or JUST) clause. Notethat JUST and JUST RIGHT carry the same meaning.

[0502] COBOLNumericEditedType

[0503] The PICTURE character-string can contain the following symbols:

[0504] B P V Z 9 0 / , . + − CR DB * cs

[0505] Other clauses: USAGE DISPLAY must be specified or implied.

[0506] Any associated VALUE clause must specify a nonnumeric literal ora figurative constant. The literal is treated exactly as specified; noediting is done.

[0507] Edited Types are different from non-edited types in that thedecimal character is stored in memory for edited types and not stored innon-edited types.

[0508] Derived from COBOLSimpleType

[0509] Public Attributes:

[0510] BlankWhenZero: Boolean

[0511] This boolean corresponds to the BLANK WHEN ZERO clause.

[0512] True if BLANK WHEN ZERO.

[0513] currencySign: String

[0514] This string represents different currency signs used in theworld, for example, $, £, DM, etc. . . .

[0515] Decimal: Boolean

[0516] The Decimal boolean exchanges the functions of the peroid andcomma in picture strings and numeric values.

[0517] If TRUE, decimals are used (e.g., 1,234.56)

[0518] If FALSE, commas are used (e.g., 1.234,56)

[0519] COBOLNumericType

[0520] Types of numeric items are:

[0521] Binary

[0522] Packed decimal (internal decimal)

[0523] Zoned decimal (external decimal)

[0524] The PICTURE character-string can contain only the symbols 9, P,S, and V.

[0525] For numeric date fields, the PICTURE character-string can containonly the

[0526] symbols 9 and S.

[0527] Examples of valid ranges

[0528] PICTURE Valid Ra nge of Values

[0529] 9999 0 through 9999

[0530] S99 −99 through +99

[0531] S999V9 −999.9 through +999.9

[0532] PPP999 0 through 0.000999

[0533] S999PPP −1000 through −999000 and

[0534] +1000 through +999000 or zero

[0535] Other clauses: The USAGE of the item can be DISPLAY, BINARY,COMPUTATIONAL, PACKED-DECIMAL, COMPUTATIONAL-3, COMPUTATIONAL-4, or

[0536] COMPUTATIONAL-5.

[0537] Possible usage values for this class are ‘binary’,‘packedDecimal’ and ‘display’, which are represented by comp-1 andcomp-2 declarations, respectively.

[0538] Derived from COBOLSimpleType

[0539] Public Attributes:

[0540] Signed: Boolean

[0541] This boolean corresponds to the SIGN clause.

[0542] True if number is signed.

[0543] SignLeading: Boolean

[0544] This attribute corresponds to the LEADING (versus TRAILING)clause.

[0545] True if LEADING.

[0546] SignSeparate: Boolean

[0547] This boolean corresponds to the SEPARATE clause.

[0548] True is SEPARATE.

[0549] currencySymbol: char

[0550] This character represents the symbol used in COBOL to representcurrencySign. (e.g., $=$, L=£, D=DM, etc. . . . )

[0551] trunc: String

[0552] The Trunc option determines whether decimal picture constraintsmust be honored for binary data items.

[0553] Values for Trunc are:

[0554] STD, OPT, and BIN

[0555] TRUNC(STD) conforms to the COBOL 85 Standard, while

[0556] TRUNC(OPT) and

[0557] TRUNC(BIN) are IBM extensions.

[0558] For more information on the Trunc attribute, please refer to“COBOL/VSE Programming Guide”

[0559] numproc: String

[0560] Numproc(PDF) imposes stricter standards on decimal sign values.

[0561] Values for Numproc are:

[0562] NOPDF, PDF, and MIG.

[0563] Use NUMPROC(NOPFD) if you want the compiler to perform invalidsign processing. This option is not as efficient as NUMPROC(PFD); objectcode size will be increased, and there may be an increase in run-timeoverhead to validate all signed data.

[0564] NUMPROC(NOPFD) and NUMPROC(MIG) conform to the COBOL 85 Standard.

[0565] Decimal : Boolean

[0566] The Decimal boolean exchanges the functions of the peroid andcomma in picture strings and numeric values.

[0567] If TRUE, decimals are used (e.g., 1,234.56)

[0568] If FALSE, commas are used (e.g., 1.234,56)

[0569] COBOL66Element

[0570] COBOL66Element represents the COBOL 66 data level.

[0571] For example: 01 DATA-GROUP PIC 9.  03 DATA1 VALUE 1.  03 DATA2VALUE 2.  03 DATA3 VALUE 3. 66 SUB-DATA RENAMES DATA1 THROUGH DATA2. 66AKA-DATA3 RENAMES DATA3.

[0572] In this example SUB-DATA refers to contents in DATA1 and DATA2.

[0573] Public Attributes:

[0574] name: String

[0575] Specifies the name or handle of the COBOL66Element.

[0576] COBOLFixedLengthArray

[0577] A COBOLFixedLengthArray should be instantiated whenever thesource for a COBOLElement has the following syntax:

[0578] LEVEL ELEMENTNAME OCCURS X TIMES.

[0579] where X can be any integer 1 or higher.

[0580] In the case when maxUpper (max upper bound) belongs toFixedArray, maxUpper denotes the upper bound of the array that isallocated in memory.

[0581] lower (lower bound) is always 1 (one) in the case of COBOL but isincluded for consistency with other languages and for clarity.

[0582] COBOLDBCSType

[0583] The PICTURE character-string can contain the symbol(s) G, G andB, or N.

[0584] Each G, B or N represents a single DBCS character position.

[0585] The entire range of characters for a DBCS literal can be used.

[0586] Other clauses: When PICTURE clause symbol G is used, USAGEDISPLAY-1 must be specified.

[0587] When PICTURE clause symbol N is used, USAGE DISPLAY-1 is assumedand does not need to be specified.

[0588] Any associated VALUE clause must specify a DBCS literal or thefigurative constant SPACE/SPACES.

[0589] The DBCSType occupies 2 bytes per character.

[0590] Derived from COBOLSimpleType

[0591] COBOLAlphaNumericEditedType

[0592] The PICTURE character-string can contain the following symbols:

[0593] A X 9 B 0 /

[0594] The string must contain at least one A or X, and at least one Bor 0 (zero) or /.

[0595] The contents of the item in standard data format must be two ormore characters from the character set of the computer.

[0596] Other clauses: USAGE DISPLAY must be specified or implied.

[0597] Any associated VALUE clause must specify a nonnumeric literal ora figurative constant. The literal is treated exactly as specified; noediting is done.

[0598] Edited Types are different from non-edited types in that thedecimal character is stored in memory for edited types and not stored innon-edited types.

[0599] Derived from COBOLSimpleType

[0600] COBOLClassifier

[0601] COBOLClassifier class is the parent class of COBOLComposedTypeand COBOLSimpleType and contains the 'typedef attribute.

[0602] The best way to think of the effect of TYPEDEFs in COBOL is aslexical substitution, similar to simple C macros. Replace the TYPEclause by everything following the TYPEDEF keyword. Then, afteradjusting the level numbers appropriately, the result has to be legalCOBOL (except for the adjusted level numbers themselves, which canexceed 49). The actual rules are quite complicated, as you might expect,so rather than describe those, here are some examples:

[0603] A simple way of enforcing shop standards for financial data:

[0604] Definition:

[0605] 1 uniform-amount typedef usage comp pic s9(6)v99 synchronized.

[0606] Reference:

[0607] 1 account-record.

[0608] . . .

[0609] 5 prior-balance type uniform-amount.

[0610] 5 current-balance type to uniform-amount.

[0611] . . .

[0612] Derived from TDLangClassifier

[0613] Public Attributes:

[0614] Typedef: boolean

[0615] User-defined types are introduced by using the TYPEDEF attribute,and referred to by the TYPE clause. If type is user-defined,‘typedef’=true.

[0616] TypeDef=False for Redefine/UNION

[0617] name: String

[0618] Specifies the name or handle of the COBOLClassifier.

[0619] COBOLAlphabeticType

[0620] The PICTURE character-string can contain only the symbol A.

[0621] The contents of the item in standard data format must consist ofany of the letters of the English alphabet and the space character.

[0622] Other clauses: USAGE DISPLAY must be specified or implied.

[0623] Any associated VALUE clause must specify a nonnumeric literalcontaining only alphabetic characters, SPACE, or a symbolic-character asthe value of a figurative constant.

[0624] Derived from COBOLSimpleType

[0625] Public Attributes:

[0626] JustifyRight: Boolean=false

[0627] This boolean corresponds to the JUSTIFIED (or JUST) clause. Notethat JUST and JUST RIGHT carry the same meaning.

[0628] COBOLObjectReferenceType

[0629] The object reference type points to an object declared in COBOLas USAGE IS INDEX OBJECT REFERENCE METACLASS OF class-name-1″ whereclass-name-1 is optional

[0630] Derived from COBOLSimpleType

[0631] Public Attributes:

[0632] className: String

[0633] Refers to the name of the object this instance refers to.

[0634] COBOLSourceText

[0635] This class contains the entire source code (including comments)and its associated line number.

[0636] Public Attributes:

[0637] source: String

[0638] fileName: String

[0639] COBOLUnicodeType

[0640] The Unicode type reperesents data stored in Unicode format.

[0641] Derived from COBOLSimpleType

[0642] COBOLInternalFloatType

[0643] The COBOLInternalFloat type captures the way floating points arerepresented in memory. For example, the value 123.45 is representedinternally as 12345 with the implied decimal marked between 3 and 4.

[0644] Possible usage values for this class are ‘float’ and ‘double’,which are represented by comp-1 and comp-2 declarations, respectively.

[0645] Derived from COBOLSimpleType

[0646] COBOLExternalFloatType

[0647] The COBOLExternalFloat type captures the way floating points aredisplayed to the user. COBOLExternalFloatTypes are the same asCOBOLNumericEditedTypes with the exception that the PIC has a +/− signbefore the mantissa and the exponent. For example, the value 123.45 maybe represented in ExternalFloatType as +12345 E -2

[0648] Possible usage values for this class are ‘binary’,‘packedDecimal’ and ‘display’.

[0649] Derived from COBOLSimpleType

[0650] COBOLAddressingType

[0651] COBOLAddressingType is used for index values, pointer values, andprocedurePointer values.

[0652] Possible usage values for this class are ‘index’, ‘pointer’, and‘procedurePointer’.

[0653] Derived from COBOLSimpleType

[0654] COBOLElementlnitialValue

[0655] Derived from TDLangElement

[0656] Public Attributes:

[0657] initVal: String

[0658] valueKind: COBOLInitialValueKind=string_value

[0659] TOTALS:

[0660] 1 Logical Packages

[0661] 23 Classes

[0662] LOGICAL PACKAGE STRUCTURE

[0663] Logical View

[0664] cobol

[0665] TDLang

[0666] 6. Illustrative Applications of the Common Application Metamodeland System

[0667] Various complex transaction, occurring across a plurality ofindividual platforms require the seamlessness and transparency of theCommon Application Metamodel. These transactions include “rich”transactions, high level group ware, and financial transactions.

[0668]FIG. 16 illustrates a simplified network configuration for a“rich” transaction where, for example, an order is entered at aterminal, and is passed to and through a Web server to a manufacturer'sapplication server. The manufacturer's application server searchesthrough it's own database server, as well as its vendors' dissimilar andincompatible database servers and databases, transparently connected bythe connectors described herein, querying for statuses, prices, anddelivery dates, of components, and placing orders for needed componentsto satisfy the order.

[0669] Strictly for purposes of illustration and not limitation, a richtransaction is illustrated with the purchase of an automobile, fromconfiguring and ordering the new automobile through financing theautomobile, collecting the elements and components the new automobile,assembling the automobile, and delivering it to the customer. Inconfiguring the automobile, consider the inclusion of, e.g., a tractioncontrol module, which may require the inclusion of one sub-set ofengines, while precluding the inclusion of another sub-set of engines,for example, for technical or performance reasons. Similarly, theselection of one color may preclude the selection of certain upholsterycombinations, for example, for reasons of inventory or availability. Ofcourse, if you don't select an engine and a transmission, you don't havean automobile. Certain choices must be made. The problem is one of “Ifyou pick ‘X’, you must also pick ‘Y’ and ‘Z’, but if you pick ‘Y’, youcan not get ‘A’ or ‘B’, and you have already selected ‘A’.” That is,selection of one component or sub-system may remove some previouslyselected components or sub-systems from the system. After configuringthe car, frequently based on the availability of selected elements inthe supply pipeline, the order is sent to the manufacturer's server forfulfillment, including manufacturing scheduling. The manufacturer wouldquery the vendors in the supply chain, for example, a transmissionvendor, who would, in turn, query controller vendors, gear vendors,housing vendors, hydraulic conduit vendors, and the like. These vendorswould, in turn query their sub-vendors.

[0670] Using the connector method and system, the dealer and customerwould configure and order the car at a terminal 3901. The configurationand order entry would be sent to the manufacturer's server 3911. Themanufacturer's server queries the servers 3921, 3931, and 3441, (whereserver 3921 could be the server for the manufacturer's in housecomponents business and for its purchasing function) or its directvendors, who in turn query third sub-vendors, 3923, 3933, and 3933. Thequeries could be in the form of “fill in the blank” SQL queries, subjectto access authorizations. The sub-vendor servers, 3923, 3933, and 3443specialized views to the vendor's servers 3921, 3931, 3441, as clients,which in turn would present specialized views to the manufacturer'sserver 3911 as a client. The data returned to the manufacturer's server3911 could be optimized with optimization and production schedulingapplications, to present a serial number and delivery date to the buyerat the dealer's server.

[0671] A further application of the connectors of the present inventionis in connection with groupware, and especially linking “islands ofgroupware” together. “Groupware” is a broad term applied to technologythat is designed to facilitate the work of groups. Groupware technologymay be used to communicate, cooperate, coordinate, solve problems,compete, or negotiate. A Groupware suite of applications is comprised ofprograms that help people work together collectively, even if locatedremotely from each other. Groupware services can include the sharing ofcalendars, collective writing, e-mail handling, shared database access,electronic meetings, video conferencing, and other activities.

[0672]FIG. 17 illustrates a group ware session spread across multiplegroup ware applications running on multiple, disparate platforms, andconnected by the connectors described herein. Specifically illustratedare two groupware systems 4010 and 4020. Each system contains e-mailenables applications, 4013 and 4023, such as e-mail, schedule/calendar,word processor, spread sheet, graphics, and CTI (computer telephonyintegration). These are supported by message API's 4015, 4025 andoperating systems, 4017 and 4027, and local groupware servers 4011 and4021. Each of the local groupware servers, 4011 and 4021, has aconnector of the present invention, an e-mail server, an e-mail database, a directory server, and a replication database. The two groupwareservers 4011 and 4021 communicate over a telecommunications medium, asthe Net, a LAN, a WAN, or even the PSTN.

[0673] E-mail is by far the most common and basic groupware application.While the basic technology is designed to pass simple messages betweenpeople, even relatively simple e-mail systems today typically includefeatures for forwarding messages, filing messages, creating mailinggroups, and attaching files with a message. Other features that havebeen explored include content based sorting and processing of messages,content based routing of messages, and structured communication(messages requiring certain information).

[0674] Workflow systems are another element of groupware. Work flowsystems allow documents to be routed through organizations through arelatively-fixed process. A simple example of a workflow application isan expense report in an organization: an employee enters an expensereport and submits it, a copy is archived then routed to the employee'smanager for approval, the manager receives the document, electronicallyapproves it and sends it on and the expense is registered to the group'saccount and forwarded to the accounting department for payment. Workflowsystems may provide features such as routing, development of forms, andsupport for differing roles and privileges.

[0675] Hypertext is a system for linking text documents to each other,with the Web being an obvious example. However, whenever multiple peopleauthor and link documents, the system becomes group work, constantlyevolving and responding to others' work. Another common multi-userfeature in hypertext (that is not found on the Web) is allowing any userto create links from any page, so that others can be informed when thereare relevant links that the original author was unaware of.

[0676] Group calendaring is another aspect of groupware and facilitatesscheduling, project management, and coordination among many people, andmay provide support for scheduling equipment as well. Typical featuresdetect when schedules conflict or find meeting times that will work foreveryone. Group calendars also help to locate people.

[0677] Collaborative writing systems may provide both realtime supportand non-realtime support. Word processors may provide asynchronoussupport by showing authorship and by allowing users to track changes andmake annotations to documents. Authors collaborating on a document mayalso be given tools to help plan and coordinate the authoring process,such as methods for locking parts of the document or linkingseparately-authored documents. Synchronous support allows authors to seeeach other's changes as they make them, and usually needs to provide anadditional communication channel to the authors as they work.

[0678] Group may be synchronous or real time, such as shared whiteboardsthat allow two or more people to view and draw on a shared drawingsurface even from different locations. This can be used, for instance,during a phone call, where each person can jot down notes (e.g. a name,phone number, or map) or to work collaboratively on a visual problem.Most shared whiteboards are designed for informal conversation, but theymay also serve structured communications or more sophisticated drawingtasks, such as collaborative graphic design, publishing, or engineeringapplications. Shared whiteboards can indicate where each person isdrawing or pointing by showing telepointers, which are color-coded orlabeled to identify each person.

[0679] A further aspect of groupware is video conferencing. Videoconferencing systems allow two-way or multi-way calling with live video,essentially a telephone system with an additional visual component, withtime stamping for coordination.

[0680] Decision support systems are another aspect of groupware and aredesigned to facilitate groups in decision-making. They provide tools forbrainstorming, critiquing ideas, putting weights and probabilities onevents and alternatives, and voting. Such systems enable presumably morerational and evenhanded decisions. Primarily designed to facilitatemeetings, they encourage equal participation by, for instance, providinganonymity or enforcing turn-taking.

[0681] Multi-player games have always been reasonably common in arcades,but are becoming quite common on the Internet. Many of the earliestelectronic arcade games were multi-user, for example, Pong, Space Wars,and car racing games. Games are the prototypical example of multi-usersituations “non-cooperative”, though even competitive games requireplayers to cooperate in following the rules of the game. Games can beenhanced by other communication media, such as chat or video systems.

[0682] Some product examples of groupware include Lotus Notes andMicrosoft Exchange, both of which facilitate calendar sharing, e-mailhandling, and the replication of files across a distributed system sothat all users can view the same information.

[0683] What makes the connectors of the present invention particularlyattractive for groupware applications is the diversity of groupwareofferings and group server architectures, implementations, andplatforms. The connector of the invention can act as a front end orgateway to the groupware server.

[0684]FIG. 18 illustrates a commercial transaction where real goods areshipped from a seller to a buyer, and various forms of electronicpayment and secured electronic payment are used by the buyer to pay theseller, with banks and financial institutions connected through theconnectors described herein. Specifically, a merchant or manufacturer4101 sells a product to a customer 4103 that he has no “history” with.The product is shipped 4605. However, the buyer 4103 does not wish to beparted from his money until the goods are received, inspected, approved,and “accepted”, while the seller 4101 does not want to give up controlof the goods until he has been paid. This fundamental commercialconflict has led to various paradigms, most involving hard copy “nearmoneys” or instruments of one form or another. Today, the financialtransactions are most frequently those involving electronic fundtransfers, and electronic versions of notes, instruments, negotiableinstruments, documentary drafts, payment orders, letters of credit,warehouse receipts, delivery orders, bills of lading, including claimson goods, that is, documents of title that purport to transfer title orphysical custody of goods to the bearer or to a named person, andsecurity interests in goods. Typically, the customer 4103 executes aninstrument in favor of the seller 4101, directing the buyer's bank 4121to pay buyer's money to the seller 4101 through seller's bank 4125.Normally, this is a simple electronic transaction between buyers andsellers who have dealt with each other before, dealing through banks orfinancial intermediaries who have dealt with each other before, and whoare using the same or compatible software applications. However, in theextraordinary case where these preconditions are not satisfied, theconnectors of the invention facilitate the electronic, bank-to-bank,side of the transaction.

[0685] While the invention has been described and illustrated withrespect to applications having a single level of application programinterfaces or converters, it is, of course, to be understood that suchapplication program interfaces or converters may be present at variouslevels in the processing hierarchy, for example between Web Clients andWeb servers, between web servers and application servers, betweenapplication servers and database servers, and between applicationservers or database servers or both and various specializedrepositories.

[0686] It is also to be understood, that while the invention has beendescribed and illustrated with respect to certain preferred embodimentsand exemplification having individual clients and individual servers,there may be multiple clients, multiple servers, and applications thatfunction as both clients and servers, as exemplified by groupwareapplications, and there might be multiple parallel lines and/or multiplehierarchical levels of application servers, data servers, and databases,as in systems for rich transactions.

[0687] While the invention has been described with respect to certainpreferred embodiments and exemplifications, it is not intended to limitthe scope of the invention thereby, but solely by the claims appendedhereto.

We claim:
 1. A method of processing an application request on an enduser application and an application server comprising the steps of: a)initiating the application request on the end user application in afirst language with a first application program; b) transmitting theapplication request to the server and converting the application requestfrom the first language of the first end user application to COBOLrunning on the application server; c) processing said applicationrequest on the application server; d) transmitting a response to theapplication request from the application server to the end userapplication, and converting theresponse to the application request fromCOBOL running on the application server to the first language of thefirst end user application; and e) wherein the end user application andthe application server have at least one connector therebetween, and thesteps of (i) converting the application request from the first languageof the first end user application as a source language to the COBOLrunning on the application server as a target language, and (ii)converting a response to the application request from the COBOL runningon the application server as a source language to the first language ofthe first end user application as a target language, each comprise thesteps of: 1) invoking connector metamodels of respective source andCOBOL target languages; 2) populating the connector metamodels withmetamodel data of each of the respective source and COBOL targetlanguages; and 3) converting the source language to the COBOL argetlanguage.
 2. The method of claim 1 wherein the end user application is aweb browser.
 3. The method of claim 2 wherein the end user applicationis connected to the application server through a web server, and the webserver comprises an connector.
 4. The method of claim 1 wherein themetamodel metadata comprises invocation metamodel metadata, applicationdomain interface metamodel metadata, and type descriptor metamodelmetadata.
 5. The method of claim 4 wherein the invocation metamodelmetadata is chosen from the group consisting of message controlinformation, security data, transactional semantics, trace and debuginformation, pre-condition and post-condition resources, and user data.6. The method of claim 4 wherein the application domain interfacemetamodel metadata comprises input parameter signatures, outputparameter signatures, and return types.
 7. The method of claim 4 whereinthe application domain interface metamodel metadata further includeslanguage metamodel metadata.
 8. The method of claim 7 wherein thelanguage metamodel metadata includes mappings between source and targetlanguages.
 9. The method of claim 8 wherein the source language isobject oriented, and the language metamodel metadata maps encapsulatedobjects into code and data.
 10. The method of claim 9 wherein thelanguage metamodel metadata maps object inheritances into references andpointers
 11. The method of claim 4 wherein the type descriptor metamodelmetadata defines physical realizations, storage mapping, data types,data structures, and realization constraints.
 12. The method of claim 1wherein the transaction is a rich transaction comprising a plurality ofindividual transactions, and further comprising processing the pluralityof individual transactions on one end user application and a pluralityof application servers.
 13. The method of claim 12 comprising passingindividual transactions among individual application servers.
 14. Atransaction processing system comprising a client, a server, and atleast one connector therebetween, a) the client having an end userapplication, and being controlled and configured to initiate anapplication request with the server in a first language with a firstapplication program and to transmit the application request to theserver; b) the connector being configured and controlled to receive theapplication request from the client, convert the application requestfrom the first language of the first end user application running on theclient to COBOL language running on the server; c) the server beingconfigured and controlled to receive the converted application requestfrom the connector and processing the said application request in COBOLlanguage with a second application program residing on the server, andto thereafter transmit a response to the application request through theconnector back to the first application program on the client; d) theconnector being configured and controlled to receive a response to theapplication request from the server, to convert a response to theapplication request from the COBOL language running on the applicationserver to the first language of the first application program running onthe client; and e) wherein connector between the client and the serveris configured and controlled to (i) convert the application request fromthe first language of the client application on the client as a sourcelanguage to the COBOL language running on the application server as atarget language, and (ii) convert the response to the applicationrequest from the COBOL language running on the application server as asource language to the first language of the client application runningon the client as a target language, each by a method comprising thesteps of: 1) retrieving connector metamodels of respective source andtarget languages from a metamodel metadata repository; 2) populating theconnector metamodels with metamodel data from the metamodel metadatarepository for each of the respective source and target languages; and3) invoking the retrieved, populated connector metamodels and convertingthe source language to the target language.
 15. The system of claim 14wherein the end user application is a web browser.
 16. The system ofclaim 15 wherein the end user application is connected to theapplication server through a web server, and the web server comprises anconnector.
 17. The system of claim 14 wherein the metamodel metadatacomprises invocation metamodel metadata, application domain interfacemetamodel metadata, and type descriptor metamodel metadata.
 18. Thesystem of claim 17 wherein the invocation metamodel metadata is chosenfrom the group consisting of message control information, security data,transactional semantics, trace and debug information, pre-condition andpost-condition resources, and user data.
 19. The system of claim 17wherein the application domain interface metamodel metadata comprisesinput parameter signatures, output parameter signatures, and returntypes.
 20. The system of claim 17 wherein the application domaininterface metamodel metadata further includes language metamodelmetadata.
 21. The system of claim 20 wherein the language metamodelmetadata includes mappings between source and target languages.
 22. Thesystem of claim 23 wherein the source language is object oriented, andthe language metamodel metadata maps encapsulated objects into code anddata.
 23. The system of claim 22 wherein the language metamodel metadatamaps object inheritances into references and pointers
 24. The system ofclaim 18 wherein the type descriptor metamodel metadata defines physicalrealizations, storage mapping, data types, data structures, andrealization constraints.
 25. The system of claim 14 wherein said systemhas a plurality of application servers and is configured and controlledto process rich transactions.
 26. A transaction processing systemconfigured and controlled to interact with a client application, andcomprising a COBOL server, and at least one connector between the serverand the client application, where the client has an end userapplication, and is controlled and configured to initiate an applicationrequest with the server in a first language with a first applicationprogram and to transmit theapplication request to the server, wherein:a) the connector being configured and controlled to receive anapplication request from the client, convert the application requestfrom the first language of the first end user application running on theclient to the COBOL language running on the server; b) the server beingconfigured and controlled to receive the converted application requestfrom the connector and process the said application request in the COBOLlanguage with a second application program residing on the server, andto thereafter transmit a response to the application request through theconnector back to the first application program on the client; c) theconnector being configured and controlled to receive the applicationrequest from the server, to convert a response to the applicationrequest from the COBOLlanguage running on the application server to thefirst language of the first application program running on the client;and d) wherein connector between the client and the server is configuredand controlled to (i) convert the application request from the firstlanguage of the client application on the client as a source language tothe COBOL anguage running on the application server as a targetlanguage, and (ii) convert the response to the application request fromthe COBOL language running on the application server as a sourcelanguage to the first language of the client application running on theclient as a target language, each by a method comprising the stepsof: 1) retrieving connector metamodel metadata of respective source andtarget languages from a metamodel metadata repository; 2) populating theconnector metamodels with metamodel data of each of the respectivesource and target languages from the metamodel metadata repository andinvoking the retrieved, populated connector metamodels; and 3)converting the source language to the target language.
 27. The system ofclaim 26 wherein the end user application is a web browser.
 28. Thesystem of claim 27 wherein the end user application is connected to theapplication server through a web server, and the web server comprises anconnector.
 29. The system of claim 26 wherein the metamodel metadatacomprises invocation metamodel metadata, application domain interfacemetamodel metadata, and type descriptor metamodel metadata.
 30. Thesystem of claim 29 wherein the invocation metamodel metadata is chosenfrom the group consisting of message control information, security data,transactional semantics, trace and debug information, pre-condition andpost-condition resources, and user data.
 31. The system of claim 29wherein the application domain interface metamodel metadata comprisesinput parameter signatures, output parameter signatures, and returntypes.
 32. The system of claim 29 wherein the application domaininterface metamodel metadata further includes language metamodelmetadata.
 33. The system of claim 32 wherein the language metamodelmetadata includes mappings between source and target languages.
 34. Thesystem of claim 33 wherein the source language is object oriented, andthe language metamodel metadata maps encapsulated objects into code anddata.
 35. The method of claim 33 wherein the source language and thetarget language are different object oriented languages, and thelanguage metamodel metadata maps encapsulated code and data between thelanguages.
 36. The system of claim 33 wherein the language metamodelmetadata maps object inheritances into references and pointers
 37. Thesystem of claim 29 wherein the type descriptor metamodel metadatadefines physical realizations, storage mapping, data types, datastructures, and realization constraints.
 38. The system of claim 26wherein said system has a plurality of application servers and isconfigured and controlled to process rich transactions.
 39. A programproduct comprising a storage medium having invocation metamodelmetadata, application domain interface metamodel metadata, and languagemetamodel metadata, and computer instructions for building a metamodelmetadata repository of source and COBOL target language metamodelmetadata.
 40. The program product of claim 39 further comprisingcomputer instructions for building connector stubs from said metamodelmetadata.
 41. The program product of claim 39 further comprisingcomputer instructions to build a connector for carrying out the stepsof: 1) retrieving connector metamodel metadata of respective source andtarget languages from the metamodel metadata repository; 2) populatingthe connector metamodels with metamodel data of each of the respectivesource and target languages from the metamodel metadata repository andinvoking the retrieved, populated connector metamodels; and 3)converting the source language to the target language.
 42. The programproduct of claim 41 wherein the metamodel metadata in the repositorycomprises invocation metamodel metadata, application domain interfacemetamodel metadata, and type descriptor metamodel metadata.
 43. Theprogram product of claim 42 wherein the invocation metamodel metadata ischosen from the group consisting of message control information,security data, transactional semantics, trace and debug information,pre-condition and post-condition resources, and user data.
 44. Theprogram product of claim 42 wherein the application domain interfacemetamodel metadata comprises input parameter signatures, outputparameter signatures, and return types.
 45. The program product of claim42 wherein the application domain interface metamodel metadata furtherincludes language metamodel metadata.
 46. The program product of claim45 wherein the language metamodel metadata includes mappings betweensource and target languages.
 47. The program product of claim 46 whereinthe source is object oriented, and the language metamodel metadata mapsencapsulated objects into code and data.
 48. The program product ofclaim 46 wherein the language metamodel metadata maps objectinheritances into references and pointers
 49. The program product ofclaim 43 wherein the type descriptor metamodel metadata defines physicalrealizations, storage mapping, data types, data structures, andrealization constraints.